On Tue, 2012-02-14 at 12:26 +0100, Patrick Ohly wrote:
So where should SyncEvolution go?
Or should I try to get it hosted on freedesktop.org? I've always
of SyncEvolution as something for all Linux desktops, not just for
There has been no feedback on the list, so I assume that it won't matter
much in practice. In the meantime fdo has accepted to host SyncEvolution
), and intend to go
ahead with it.
Mirroring the git repos will be trivial. Migrating the bugs will be a
bit harder. I've experimented with Bugzilla's importxml.pl script in a
local Bugzilla installation. It seems to work fairly well, after fixing
the exported .xml a bit.
importxml.pl merges all comments in the old tracker into the description
in the new tracker. E-mail addresses are copied and shown, just as they
were in bugs.meego.com
. The bottom of the description links back to the
original bug. I intend to use that back link to close the corresponding
bugs in bugs.meego.com
. That'll inform users that the bug has moved.
My plan is to have only two accounts initially in bugs.freedesktop.org
myself and an anonymous "SyncEvolution team" account. That means that
users who want to be kept informed about migrated bugs will have to sign
up in fdo and CC themselves to bugs of interest anew.
Ove, as maintainer of the Maemo port, can you perhaps create an account
already before the migration? In that case bugs related to you could be
assigned properly from the start. I'd also like to have you as default
assignee for the "Maemo 5" component. Okay?
Do we need a separate "Harmattan" component or should we use just a
single "Maemo" component for all Maemo releases?
Regarding timing, I intend to clean up the current bug list this week
and next, then perhaps migrate end of next week. Tollef, I would send
you instructions about the bug tracker components and a .xml file that
can be imported directly with importxml.pl. Okay?
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.