Re: Moving Evolution bugs to gnome.

[Elijah Newren <newren gmail com>]

Well, my $0.02...

On Mon, 31 Jan 2005 18:19:03 +0100, Olav Vitters <olav bkor dhs org> wrote:

> I need some input from everyone on the following:
> * Exact products to move over. Are there other products besides
>   Evolution that should be moved over?

I was hoping that we could move other dependencies such as Gal,
GtkHtml, Bonobo, and libsoup (an indirect dependency via e-d-s) over. 
I think it would just make it easier to allow us to manually reassign
bugs that are misfiled than to ask the user to refile in a different
location.

> * Dependencies. Some bugs depend on bugs in other products. What should
>   be done with these?

If those products aren't part of the move, I'd suggest adding a
comment--"This bug depends on ximian #xxxxx, <summary-of-bug>"

> * Duplicates. Same as above, some bugs have been duplicated to other
>   products. Newer Bugzilla versions keep the duplicates in a separate
>   table. This table is checked for consistency by sanitycheck.cgi.
>   I suggest to move the relevant bugs over to the other products. Same
>   for non-Evolution bugs duplicated against a Evolution bug.

I think you're probably right that moving the bugs to the appropriate
product before doing the export would probably be the best way to keep
things sane.

> * Priority vs severity. B.x.c has critical/major/normal in the Priority
>   field. This is the Severity field in b.g.o. I can move this easily
>   over, but:
> * Time tracking. B.x.c uses the Severity field for some time tracking
>   purpose. B.g.o has no field for this. Bugzilla 2.18 (?) will have
>   time tracking features, but we're at 2.16.

Just ask them how they'd like to map each of those time estimates to
one of the priorities: Immediate, Urgent, High, Normal, Low.  I'm
really against the idea of having either priority or severity fields
get any kind of time fields.

Personal off-the-wall opinion: I think time fields are a bad idea
altogether.  Trying to figure out how long it will take to fix things
is difficult and error-prone, and I believe would end up sapping away
time from doing actually development.  I think it's like feature-based
releases in that people waste time based on trying to figure out what
features will exist in a given future release (and then either fail to
deliver when they find out they can't make it or punt their release
forever while letting features that are useful for users not get any
use because of no stable release being made).


Thanks for all the awesome work, Olav.

Elijah