Bug Triage (was Re: scheduled transactions make bad transact ions with 1.8.9 ?)

Steve Romanow slestak at cavtel.net
Wed Jun 23 10:39:30 EDT 2004

Hash: SHA1

On Wed, June 23, 2004 10:34 am, Englisch, Volker (NIH/NCI) said:
>> >>>
>> > Would you prefer we start with oldest or newest unconfirmed bugs.
>> Maybe
>> > each of us should start from different end.
>> I don't have a preference.  Just being able to close out bugs that
>> are no longer a factor, or bugs that cannot be reproduced... and pushing
>> back bugs that don't have enough information..  and being able
>> to reproduce bugs...  That would help significantly.
>> If I can go to a bug and easily reproduce it, I can (generally) easily
>> fix it.  Sometimes the reproduction part is the most challenging
>> aspect!
> I was thinking to look at the oldest bugs first hoping that most of those
> could be closed out because they can not be reproduced in the newer
> versions.
> Maybe the easiest for now would be to one of us start from the top while
> the
> other starts at the bottom or one takes the bugs with even bug numbers
> while
> the other one looks at the odd ones.  I'm OK with any approach.

Ok, Why dont you start with oldest, I'll start with newest.  I am having
some difficulty with the machine I was going to use as my sandbox, but I
should be able to start shortly (within a week or so).

> Here is a question that came up yesterday when I looked at a (randomly
> selected) bug (http://bugzilla.gnome.org/show_bug.cgi?id=143992).
> One could argue that the reported bug is a feature which doesn't need to
> be
> addressed.  How should bugs like this be handled?  Should we merely state
> that the behavior has been confirmed and leave it up to the developer to
> decide what should be done?
> -- Volker
It prob wouldnt hurt to confirm it, and pass it on.  Let Linas and Derek
decide on inclusion/priority.

Version: GnuPG v1.2.4 (GNU/Linux)


More information about the gnucash-devel mailing list