SF bug tracker import for Hugin - experimental

Hi,

We normally import bugs into a standalone instance of Launchpad, then
into staging, then into production. I'll check they import correctly
into a standalone version as soon as I can, and arrange an import into
staging for you to look at.

> 1. is it OK to use Launchpad's bug tracker without hosting the code
> itself on Launchpad? We're happy with hosting the code on
> SF. Moreover it is Hg, while Launchpad offers bzr only. We intend to
> stay with Hg for the foreseeable future.

Of course, that's absolutely fine.

> 2. Does Launchpad offer some kind of dump/export functionality from
> the Launchpad tracker? Not that we need it right now, but it is nice
> to know that we are not inside a walled garden. SF's tracker was
> good when we started. Now it is hopelessly inadequate, but at least
> they don't make it difficult to move.

I've just looked and, yes, we have a script to export bugs from
Launchpad. I haven't ever used it, and I don't remember anyone ever
requesting it, but it's there, tested and maintainted.

We also have a web API - see https://help.launchpad.net/API - with
which you should be able to get at (and manipulate) all your bug
data. The web API also covers many/most other parts of Launchpad.

Regardless of the how, we also don't want to hold your bugs
hostage. If you want your data, we'll help you get it.

Gavin.

Dear Gavin,

thank you for the very forthcoming and fast response. I'll share this information with our community and have them play with the staging version once you forward me the URL. I sincerely hope for positive feedback from the community so that we can go into production using Launchpad to track our bugs. I would not be moving away from SourceForge if their bug tracker did serve our needs adequately. Our project has grown, while their tracker has stayed put. I know from my experience with Launchpad that it is a state-of-the-art bug tracker used for much larger projects than Hugin and we'd have room to grow here. No intention to use the export script, but it is good to know that you have a sane attitude toward data migration.

The next steps as I see them:
* you communicate to me/us the staging URL
* we play for a week or two on the staging URL and come to a decision about the migration
* if the decision is positive, we freeze our current bug trackers, run the export/import once again, this time to production Launchpad.

At the same time, I contacted the person who currently owns https://launchpad.net/hugin - he has moved on and is no longer interested maintaining it. He offered to turn over ownership to me. I hope we can get this done before the the production export/import so that Hugin will have a new home

is this OK for you?

Thank you for making us feel welcome
Yuv

Hi,

I needed to massage the bug import XML a bit to get it to import
cleanly. The data you gave me is fine, but Launchpad only permits
50000 characters in the description and comments.

I have resurrected an old script to modify these descriptions and
comments. It truncates them and adds a line referring the reader to a
bug attachment with the complete description or comment. Let me know
if that's a problem.

Anyway, the bugs now import fine. I'll get them onto staging tomorrow;
it's down right now for a refresh. I'll let you know as soon as
they're ready to look at.

Gavin.

Thanks for the update Gavin. I don't think the bug attachment for long/trunkated text will be an issue. We'll see when we can play with them in staging.

I started preparing the community for the test and upcoming changes. The discussions start to... warm up. interesting times ahead, as with every change.

One issue that came up from the community and that I did not foresee: integration of the bug tracker (bt) with the repository (repo).

So there are now four different scenarios for a migration to LP (not sure all of them are possible)
1) migrate just bt to LP - no repo integration
2) migrate bt & repo to LP - repo integration as free bonus but we have to adopt bzr
3) migrate bt to LP, mirror hg/SF on bzr/LP, integration *maybe* (need to be tested)
4) migrate bt to LP and research/write custom post-commit hook for hg/SF to talk with LP using launchpadlib

Do you have any experience with 3) or 4) ? I raised the topic of repo migration with the community but I am reluctant to introduce even more change at this stage, since we just adopted Hg last spring.

Thank you for your continued support
Yuv

Hi,

The bugs can be seen at:

  https://bugs.staging.launchpad.net/scriptify

(Scriptify is a project of mine which has no bugs filed; I imported
there because I already have the necessary permissions to configure
the project correctly.)

The Launchpad staging environment is refreshed each weekend, so these
bugs will disappear then. I can get them imported again on Monday.

The downside to staging is that you will not be able to see the bug
email that is sent out from Launchpad; because staging is based on
production data we prevent it from sending mail to the outside.

I'll ask a colleague to answer your questions about the repository.

Gavin.

Thank you very much, Gavin.

Do I assume correctly that only open bugs have been imported (the numbers seem to confirm that, as well as anecdotal search evidence)?

I like the reference to the sf bug number (small and bold next to the LP bug#), which will help find the original data in case it is needed, although I was not able to bring up any search result entering the sf-XXXXX bug number. Is there a way to search for a bug by its old bug number?

https://bugs.staging.launchpad.net/scriptify/+bug/666158 should have a text attachment to it, but https://bugs.staging.launchpad.net/scriptify/+bug/666158/+attachment/1706471/+files/fr.po returns a 404 error.

Was it missing in the XML file I provided? Or is it a staging thing not to add attachments at this point and only show them in production? The original bug report is at https://sourceforge.net/tracker/?func=detail&aid=2973472&group_id=77506&atid=550443

I could not find any of the 50K character truncated bugs. If it's trivial for you to point me to it, can you do so, please? else, I don't think it is that bad. With the original sf bug number we're covered.

What I like a little bit less is that the timestamp on all bugs has been updated, so the "last changed" information will become irrelevant for a little while after the migration. any chance to avoid this on the production import?

these are my thought so far. I already know LP from interacting with it for other projects and it is vastly superior to the SF bug tracker, but I guess you know that.

How long will this staging branch be available for our community to try / play with? Not everybody has time to do so right away. The "natural speed" of the community is around 3-4 weeks. More than what I would like it to be. If it was my decision, we'd be migrating to LP's bug tracker as the next step.

Have a good week
Yuv

> Thank you very much, Gavin.
>
> Do I assume correctly that only open bugs have been imported (the
> numbers seem to confirm that, as well as anecdotal search evidence)?

No, all bugs have been imported. Closed bugs (invalid, won't fix, fix
released) are not shown by default in summaries and lists; you must do
an advanced search to select those statuses that you're interested
in. (These searches can be bookmarked safely if you often need to
refer to these lists.)

> I like the reference to the sf bug number (small and bold next to the
> LP bug#), which will help find the original data in case it is needed,
> although I was not able to bring up any search result entering the
> sf-XXXXX bug number. Is there a way to search for a bug by its old bug
> number?

The reference is stored as the bug "name" attribute. I don't think
it's editable through the web UI, only via the web-service API. You
can use it to get to your bug like so:

  https://staging.launchpad.net/bugs/${name}

So, for example:

  https://staging.launchpad.net/bugs/sf-1692957

will redirect you to:

  https://bugs.staging.launchpad.net/scriptify/+bug/665073

> https://bugs.staging.launchpad.net/scriptify/+bug/666158 should have a
> text attachment to it, but
> https://bugs.staging.launchpad.net/scriptify/+bug/666158/+attachment/1706471/+files/fr.po
> returns a 404 error.
>
> Was it missing in the XML file I provided? Or is it a staging thing
> not to add attachments at this point and only show them in production?
> The original bug report is at
> https://sourceforge.net/tracker/?func=detail&aid=2973472&group_id=77506&atid=550443

I'm looking into this. It could be that the staging librarian has been
erased since last week, but that staging has not been refreshed yet.

> I could not find any of the 50K character truncated bugs. If it's
> trivial for you to point me to it, can you do so, please? else, I
> don't think it is that bad. With the original sf bug number we're
> covered.

Here's the full list:

  https://staging.launchpad.net/bugs/sf-2073115
  https://staging.launchpad.net/bugs/sf-2177387
  https://staging.launchpad.net/bugs/sf-2475807
  https://staging.launchpad.net/bugs/sf-2789090
  https://staging.launchpad.net/bugs/sf-2855513
  https://staging.launchpad.net/bugs/sf-2871573
  https://staging.launchpad.net/bugs/sf-2912492
  https://staging.launchpad.net/bugs/sf-3032110

Unfortunately the attachments seem to have disappeared too. I'll let
you know when I've found out more.

> What I like a little bit less is that the timestamp on all bugs has
> been updated, so the "last changed" information will become irrelevant
> for a little while after the migration. any chance to avoid this on
> the production import?

Sure, that seems odd, possibly a bug. I'll look into it.

> these are my thought so far. I already know LP from interacting with
> it for other projects and it is vastly superior to the SF bug tracker,
> but I guess you know that.

:)

> How long will this staging branch be available for our community to
> try / play with? Not everybody has time to do so right away. The
> "natural speed" of the community is around 3-4 weeks. More than what I
> would like it to be. If it was my decision, we'd be migrating to LP's
> bug tracker as the next step.

The staging environment should have been cleared over the weekend. I
assume there was a problem. I'll get these bugs imported into our new
qastaging environment which will not be cleared for another 2-3
weeks. If you still need the bugs after that I can get them imported
again.

Gavin.

> Unfortunately the attachments seem to have disappeared too. I'll let
> you know when I've found out more.

I've discovered the following with the help of one of my colleagues:
the staging environment sometimes gets a non-db restore, which wipes
the librarian's disk files. I've filed bug 669540 about it.

> I'll get these bugs imported into our new qastaging environment
> which will not be cleared for another 2-3 weeks.

Unfortunately it's getting late in my day now so I'll probably have to
do this tomorrow morning (from 0900 UTC). I think this will resolve
the librarian issues and give you more time to evaluate.

Gavin.

> What I like a little bit less is that the timestamp on all bugs has
> been updated, so the "last changed" information will become irrelevant
> for a little while after the migration. any chance to avoid this on
> the production import?

Are you referring to the dates in the activity log? For example:

  https://bugs.staging.launchpad.net/scriptify/+bug/665145/+activity

Let me know which dates appear wrong and I'll see if there's something
we can do about them.

Gavin.

> Unfortunately it's getting late in my day now so I'll probably have
> to do this tomorrow morning (from 0900 UTC). I think this will
> resolve the librarian issues and give you more time to evaluate.

Hi, the bugs are now imported to qastaging:

  http://bugs.qastaging.launchpad.net/scriptify

They will have different bug numbers from those in staging, so it's
not possible to simply replace staging with qastaging in URLs that
contain bug numbers, but the bug name links will work. Here's an
update list of bugs with attachments:

  https://qastaging.launchpad.net/bugs/sf-2073115
  https://qastaging.launchpad.net/bugs/sf-2177387
  https://qastaging.launchpad.net/bugs/sf-2475807
  https://qastaging.launchpad.net/bugs/sf-2789090
  https://qastaging.launchpad.net/bugs/sf-2855513
  https://qastaging.launchpad.net/bugs/sf-2871573
  https://qastaging.launchpad.net/bugs/sf-2912492
  https://qastaging.launchpad.net/bugs/sf-3032110

Gavin.

> > What I like a little bit less is that the timestamp on all bugs has
> > been updated, so the "last changed" information will become irrelevant
> > for a little while after the migration. any chance to avoid this on
> > the production import?
>
> Are you referring to the dates in the activity log? For example:
>
> https://bugs.staging.launchpad.net/scriptify/+bug/665145/+activity
>
> Let me know which dates appear wrong and I'll see if there's something
> we can do about them.

actually what I meant was on the overview page, where all imported bugs are listed with last changed "on 2010-10-28"

https://bugs.staging.launchpad.net/scriptify

you made me aware that there are more dates in the system than I though.

In an ideal world, the timestamp of each individual activity is preserved. And most of it is in the current import. I see that all comments inside a bug have the right dates. I don't know how much effort it would mean to fix what is left and I am aware that I am not paying you for this and appreciate already very much the efforts you are doing for our project.

The most important timestamp is the date on which the report was filed. It is immutable and helpful in identifying bugs that may be obsolete/outdated. If it is this date that appears as "last changed" on the overview page after the import, it's good enough.

The second most important timestamp is the date of the last activity. This changes as bugs evolve (although: are comments registered in the log? imported comments seems not to), so even if it is the filed-date; or filed-date+1, that's good enough. The problem is when that date is the same date across all bugs, as we have it now.

Timestamps for in-between activities are relatively unimportant, so if it is too much effort to reflect them exactly I would just assign something arbitrary to them, relative to filed-date, so not to affect the bug seniority order.

I understand there is seniority order information in the bug# as well, but that information is incomplete because it does not tell me where on the timeline the bug is. The filed-date has important implicit information because it tells me roughly against which version of the codebase it is filed.

Thank you also for the:
* sf-XXXXXX bug reference link
* list of all truncated bug reports
* looking into the staging librarian issue. I just tested and it has not been fixed yet, but at least it is a known issue. Please let me know when it is fixed so that I can unleash the horde of critical project members on the new issue tracker

Last but not least, one project member reports that he can't log on into staging with his usual launchpad credentials. Any idea what could be causing his bad experience?

Thank you again for all of your effort. I appreciate your work a lot and I understand that when the work-day is over it is over. Don't hesitate to push back at me if the heat is too high. I've had a few very intense days on my end as well, with a critical deadline Nov 1 and with a two years old doing a 40°C fever while dealing with a viral and bacterial infection at the same time. I wish I could manipulate my sleep timestamps the same way you can manipulate log entry timestamps but I am afraid my body won't be fooled by such manipulation :-)

Hi again, Gavin.

I just realized while clicking on the links to the bugs that the attachment thing has been fixed... in qastaging. Apology for not realizing that earlier.

The attachments all look good now. For the truncated text, I don't know how anally retentive Canonical wants to be about hiding email addresses. They are there in plain text to see in the attachment, as opposed to the actual bug page where the email address is hidden.

I don't think this is a show stopper because the email address is anyway published on the publicly available HTML output of the SF bug tracker. If I was aiming for perfection, I would filter out the email addresses from the attachment and replace them with <email address hidden> just like on the bug report

https://bugs.qastaging.launchpad.net/scriptify/+bug/661613
http://qastaging.launchpadlibrarian.net/57530834/hugin-bug-2073115-full-description.txt
(in the first lines of the report)

thanks
Yuv

Hi Gavin,

Just a quick update on our end. The evaluation process is nearly finished and the feedback is mostly positive.
I'm still waiting for one stakeholder to get back with his comments and don't want to preempt our decision, but the indication is strong that we'll be ready to go ahead in the coming days.

Below I:
* detail our evaulation process status
* list the steps of the next stage as I see them - please complete / add your comments, your timeline, your availability
* list the (little) negative feedback I collected in great detail, hoping you / the Launchpad team can extract value from it for your further development process
* summarize some of the positive feedback I collected.

**EVALUATION STATUS**

There was (and still is) some learning to do on our end, but the majority of the representative group of six stakeholders polled (two devs, one builder, one packager, one triager, one user and myself) see the value in moving our bug tracking to Launchpad.

I'm still waiting for one stakeholder to get back with his comments and don't want to preempt our decision. I feel that a consensus is in reach in the next days. If there is no consensus, I'll have to get back to the project as a whole. If we can reach a consensus, I'll initiate the necessary steps on our end and touch base with you to kick off the actual migration process.

**NEXT STAGE**

The next stage is the actual migration. There will be a transitioning time during which our tracker won't be available, and I kindly ask for your help and support to keep that time to the strict minimum.

The steps as I see them:
1. I freeze our old tracker
2. I export the bugs to the XML format you've been using for this test-import
3. You do your magic and import the bugs
4. We go live

Unless you think that more testing is required, I am confident that reproducing with the latest export what you did with the previous one will yield a usable result. The timestamps etc. are a detail we can live with.

I'd like to minimize the time between 1 and 4. I am on the East Coast and I understand you're in the UK? I would freeze our tracker late at night and produce the export so that it will be available for you early morning on the day of the migration. How does your calender look? Is there any day of the week that is preferable to you / that you can block to get this task done? Please suggest a few possible days between now and the end of the month, I'll adapt my schedule to your availability (and to the project's decision).

As a target, I'd like the bugs to be stored at https://bugs.launchpad.net/hugin - it was abandoned for a while and the previous maintainer transferred it to our team.

From my perspective, this cover all the next stage. Are there things I am missing? Things that you would like to add?

**ISSUES**

I list below the issues / negative feedback encountered, hoping that you / the Launchpad development team finds value in them for the further development of the Launchpad infrastructure.

* Account registration - a stakeholder complained at length about the burdens of account registration. His created password was not accepted three times. The captcha was painful. Not a good first experience, even if it is a one-off. I understand the need for all of these safety measures, but I think it is possible to do better. These would be my suggested solutions:
1 - add OpenID consumer functionality to simplify and streamline account creation
2 - generate the first password rather than asking the user to create one
3 - generate the form client-side with JavaScript rather than server-side will prevent most spambots from even seeing the form
4 - there are also more effective captcha solutions, but it would take too long to describe them here

* Initial View - a developer reports that when starting the bug tracker the bugs are always sorted by importance. He would find it nice if the last sorting order would be used.

* Terminology - A non-native speaker reports "least recently changed" as confusing, and as second non-native speaker I can confirm. Suggestion: "last changed" instead of "most recently changed" and "first changed" instead of "least recently changed". May not be elegant, but more people understand last/first than least/most.

* Latency/Capacity - we had two reports that login functionality seemed to have capacity problems, e.g. "Service temporarily unavailable". Do I guess correctly that this is related to staging and that the production environment is faster / more stable?

**PRAISE**

As you can read above, the issues we encountered were really just small details. Papercuts. In the greater scheme of things we're very pleased with the test.

I found you to be a very supportive and responsive partner in managing our data on its migration path. It makes me confident that our data is in good hands.

Another stakeholder praised the email functionality (although it was disabled for this test) and stated that Launchpad "is much more usable than sourceforge or bugzilla and [he] can see [him]self using the email interface for everything".

When discussing the reduction from our current three trackers (bugs, patches, feature requests) to a single queue, one developer praised the Blueprint functionality as giving structure and process to feature requests.

The other developer liked the flexibility with which reports can be moved into Q&A or made relevant to another project rather than being declared invalid - something that happens quite often on our current tracker.

All in all, I feel that we are progressing nicely and I look forward to see our project thrive on Launchpad for the foreseeable future.

Thank you!
Yuv

Hi Yuv,

It's been a while since I last replied, so I'll try and reply to all
of your messages in one.

> Last but not least, one project member reports that he can't log on
> into staging with his usual launchpad credentials. Any idea what
> could be causing his bad experience?

Because staging does not send out email (actually it does, but we
capture it before it gets routed externally) I don't think it's
possible to register on staging. You need to register on production
and way for staging to be refreshed from production.

(Though this may not be true anymore due to Launchpad's use of a
shared single-sign-on system).

> The attachments all look good now. For the truncated text, I don't
> know how anally retentive Canonical wants to be about hiding email
> addresses. They are there in plain text to see in the attachment, as
> opposed to the actual bug page where the email address is hidden.
>
> I don't think this is a show stopper because the email address is
> anyway published on the publicly available HTML output of the SF bug
> tracker. If I was aiming for perfection, I would filter out the
> email addresses from the attachment and replace them with <email
> address hidden> just like on the bug report

Ah, I didn't think of that! I don't really have time to address that,
but you could modify the export XML before sending it to me to remove
email addresses from bug descriptions and comment text if you wish.

Migration:

> The steps as I see them:
> 1. I freeze our old tracker
> 2. I export the bugs to the XML format you've been using for this
> test-import
> 3. You do your magic and import the bugs

This breaks down to:

- Import bug data locally to check it's okay. Manually fix any
  problems in the import.

- Import into qastaging. Fix any other issues that arise.

- Import into production.

It's unlikely, but there could be problems at any of those steps that
prevents me from being able to proceed.

> 4. We go live
>
> Unless you think that more testing is required, I am confident that
> reproducing with the latest export what you did with the previous
> one will yield a usable result. The timestamps etc. are a detail we
> can live with.

I'm glad you're okay to live with those. Like with the email addresses
in attachments, I don't have capacity to produce a fix for that.

> I'd like to minimize the time between 1 and 4. I am on the East
> Coast and I understand you're in the UK? I would freeze our tracker
> late at night and produce the export so that it will be available
> for you early morning on the day of the migration. How does your
> calender look? Is there any day of the week that is preferable to
> you / that you can block to get this task done? Please suggest a few
> possible days between now and the end of the month, I'll adapt my
> schedule to your availability (and to the project's decision).

Sounds fine to me. If the import goes wrong for any reason I suppose
you can unfreeze your tracker for the day so that your work is not
interrupted. We could then address those problems without pressure.

Alternatively we could do the following:

- You freeze your tracker and export in the morning, East Coast time.

- Tell me, I'll start on step 3 immediately. I have a colleague in the
  US who I can hand over to if this takes a long time, but it probably
  won't. I normally work until 1800 UTC.

- Either you can go live, or unfreeze your tracker if things have not
  gone according to plan.

Your call, I don't mind.

I can do November 18th, 22nd, 23rd, 24th, 25th, 29th, 30th, starting
at 0900 UTC. I can do later dates too, just ask. I'll be working most
days from now until Christmas.

> * Account registration - a stakeholder complained at length about the
> burdens of account registration. His created password was not
> accepted three times. The captcha was painful. Not a good first
> experience, even if it is a one-off. I understand the need for all
> of these safety measures, but I think it is possible to do
> better. These would be my suggested solutions:
>
> 1 - add OpenID consumer functionality to simplify and streamline
> account creation

I think that's a popular request:
  https://bugs.launchpad.net/launchpad-foundations/+bug/210943

> 2 - generate the first password rather than asking the user to
> create one

Interesting suggestion. Can you file about about it at:
  https://bugs.launchpad.net/launchpad-foundations/+filebug

> 3 - generate the form client-side with JavaScript rather than
> server-side will prevent most spambots from even seeing the form

We have been discussing something similar recently, though for
different reasons. I think that spammers will figure that out soon
enough though (indeed, employing Amazon's Mechanical Turk is one such
way around both captchas and javascript-only forms).

> 4 - there are also more effective captcha solutions, but it would
> take too long to describe them here

I haven't been through registration for a long long time, probably
before captchas, so I can't comment, but if you're interested please
file a bug at:
  https://bugs.launchpad.net/launchpad-foundations/+filebug

> * Initial View - a developer reports that when starting the bug
> tracker the bugs are always sorted by importance. He would find it
> nice if the last sorting order would be used.

There may be a bug for this at https://bugs.launchpad.net/malone. If
not, a bug can be filed from there too.

> * Terminology - A non-native speaker reports "least recently changed"
> as confusing, and as second non-native speaker I can
> confirm. Suggestion: "last changed" instead of "most recently
> changed" and "first changed" instead of "least recently
> changed". May not be elegant, but more people understand last/first
> than least/most.

That's interesting! Again, please file a bug at:
  https://bugs.launchpad.net/malone/+filebug

> * Latency/Capacity - we had two reports that login functionality
> seemed to have capacity problems, e.g. "Service temporarily
> unavailable". Do I guess correctly that this is related to staging
> and that the production environment is faster / more stable?

There were some performance issues with single-sign-on last week, but
they have been resolved. It's possible it was just a bad moment. In
any case, sorry about that.

> I found you to be a very supportive and responsive partner in
> managing our data on its migration path. It makes me confident that
> our data is in good hands.

Excellent, I'm sorry I've been a bit quiet lately.

> Another stakeholder praised the email functionality (although it was
> disabled for this test) and stated that Launchpad "is much more
> usable than sourceforge or bugzilla and [he] can see [him]self using
> the email interface for everything".

That's great to hear. We're working on additional controls for bug
subscriptions right now, so it's soon going to get even better :)

Gavin.

Hi Gavin

thanks for the reply and for your availability. I filed a few bug reports as per your suggestion.

For our migration let's stick with my original timeplan. I'm a night-owl and 9:00 UTC is 4:00 AM here. Plus we don't have many active users from the Asia/Pacific time zone in our tracker.

Let's do November 22, which means that you can expect to have a download link on this thread by November 22 9:00 UTC.

The project can live the whole Monday without bug tracker. I don't think we'll need to revert to the old bug tracker but I like to have everything covered, just in case. It will be your call: if you find a roadblock, we'll revert and try again later.

have a good weekend
Yuv

> Let's do November 22, which means that you can expect to have a
> download link on this thread by November 22 9:00 UTC.

I've put that in my calendar.

Have a good weekend too!

Gavin.

Good morning Gavin,

The file is ready at http://www.photopla.net/hugin_final_101122.xml

I'm hitting the pillow soon and will check back in about six hours. Our two years old fell sick this weekend. Not sure yet how serious it is. If the past two months are an indication, I'll be busy taking care of him tomorrow.

I wish you a better start of the week than mine.

Yuv

Hi Yuv,

The bugs are all imported, but not yet visible. To make them visible
there's one quick configuration change that you need to make: visit
https://bugs.launchpad.net/hugin/+configure-bugtracker and select "In
Launchpad" under "Bugs are tracked".

Let me know if there are any issues.

Gavin.

Done! Thanks a lot, Gavin.

Question: what is the snail mail address to reach you at your office and how many people are in your team?

We're gearing up our seasonal cookies production and I'd like to send a small token of gratitude your way.

http://panospace.wordpress.com/2008/12/31/december/

Yuv

I've replied privately to your kind offer of cookies :)