Hi,

On Mon, 2004-04-05 at 22:28, David Neary wrote:

Up until earlier today there were over 30 versions of the GIMP to choose from in Bugzilla. This has been reduced to 4 - 1.0.x, 1.2.x, 1.3.x, 2.0.0 and Current CVS. I question whether we'll need 2.0.1, 2.0.2, etc at all, and personally I'm happy having just ".x" for the major branches, but anyway...

I think we should stick to having 2.0.1, 2.0.2 etc. It's often important to know if the user reporting a bug is using a particular release in which the bug is supposed to have been fixed.

So - I just wanted to say a big thank you to Luis Villa for doing this today with his magic SQL fingers.

I second that. Thanks Luis - and thank you Dave for taking the initiative to clean this up.

We also talked about the problem of dead/completed milestones - it doesn't make sense to have any bugs on 1.2.x milestones or 1.3.x milestones any more (or, indeed, 2.0.0). But it doesn't make sense to delete them either.

True.

Unfortunately, Bugzilla doesn't (yet) have the concept of a completed milestone, allowing milestones to be hidden from the list for people doing triage. We can, however, sort these so that the active milestones are at the top of the list. Does this sound like a good idea?

I think we should stick to a numerically sorted list as I find this more intuitive. When using non-numerically (or non-alphabetically for that matter) sorted list I often find myself looking for an entry in the wrong place...

Sincerely,
Brix

Hi,

Henrik Brix Andersen writes:

I think we should stick to having 2.0.1, 2.0.2 etc. It's often important to know if the user reporting a bug is using a particular release in which the bug is supposed to have been fixed.

Yes, I think we should continue to have the fine grained version info in bugzilla. When a branch comes to an end, we can always merge the versions as it was done today. Thanks a lot for doing that.

I think we should stick to a numerically sorted list as I find this more intuitive. When using non-numerically (or non-alphabetically for that matter) sorted list I often find myself looking for an entry in the wrong place...

I second that.

Sven

There is another thing that could be cleaned up in Bugzilla: moving all 1.3.x bugs that are in RESOLVED state to the CLOSED state and adding a comment saying that the fix is part of the official release 2.0.0 (or 2.0.1 soon). This helps the users who are searching for bugs by telling them in which stable release some bug was fixed. I got some positive feedback about that in the past, so it looks like these comments are useful. This can also help us by reminding us of which bugs are only fixed in CVS or in developer's releases (RESOLVED) and which ones are fixed in stable releases (CLOSED).

I have done that in the past for the 1.2.x releases and I can do it again for 2.0.x. Unfortunately, this will generate a lot of notifications because of the additional comments that should be added. So before starting with that, I would like to be sure that nobody objects. Any comments?

-Raphaël

On Tue, 6 Apr 2004 23:13:18 +0200, David Neary wrote:

Raphaël Quinet wrote:

There is another thing that could be cleaned up in Bugzilla: moving all 1.3.x bugs that are in RESOLVED state to the CLOSED state and adding a comment saying that the fix is part of the official release 2.0.0 (or 2.0.1 soon).

Personally I don't see the need. I've personally looked at the milestones to see when bugs were fixed (and the comments), and I have never really seen a benefit to having both resolved and closed - in fact, in my company's installation of bugzilla we reduced the lifecycle of bugs to 4 states - New, Assigned, Resolved and Reopened, which suits our usage patterns fine.

As for the target milestones, they are not always reliable because some bugs are fixed without having a target assigned to them, and some others are fixed before the expected target milestone. At my company, we use something else than bugzilla (alas!) but we have the equivalent of "resolved" and "closed": a bug is "closed" when the fix has been verified and is part of an official product release, but before that it is only "resolved".

You mention a benefit to users, but I don't think personally that users (in general) use bugzilla to an extent where this is a large factor. Nor do people in general have a deep knowledge of the nuances of "resolved" and "closed".

I agree that non-developers do not care that much about "resolved" vs. "closed", but for 1.2.x I got some feedback from users who liked the additional comment saying in which stable release a given bug was fixed. I am guessing that it helped those who were not sure if they had to upgrade to the latest release or if another version was good enough for them. This is useful for those who rely on third-party binary packages and may not always have the last version for their platform.

I think that the overhead of going through the bugs and changing them to CLOSED probably outweighs the benefit of it. But if you feel otherwise, I don't mind (although slogging through 300 bugzilla mails is going to be a pain).

Yes, and updating the bugs is going to be a pain as well, because this cannot be completely automated. But I think that it is useful anyway. Before doing anything, I will wait a few more days and see if there are other opinions posted here.

-Raphaël