RSS/Atom feed Twitter
Site is read-only, email is disabled

Preparing for 2.0 - bugzilla

This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

1 of 1 message available
Toggle history

Please log in to manage your subscriptions.

Preparing for 2.0 - bugzilla David Neary 22 Jul 21:50
David Neary
2003-07-22 21:50:04 UTC (over 20 years ago)

Preparing for 2.0 - bugzilla

Hi all,

As most of you know, we are approaching a feature freeze leading up to the next stable release (I don't want to get into any fights - although I personally think 2.0 is better, I don't actually care what it's called, as long as it gets released).

A feature freeze means we draw a line in the sand and say "no more features get in here" - after the feature freeze, there should be no changes accepted into CVS unless they fix behaviour which should work, but doesn't.

So we have the problem of where (and when) to draw the line. The when is provisionally the end of camp, giving people the chance for a feature-filled weekend from the 6th to the 10th. The where is more difficult. There are currently 361 bugs open against the GIMP with either a milestone 1.3.x or milestone --. That means that currently, there are 361 tasks which people would like to see done before the next release. Many of these are small - of course, the problem is deciding which can/should be done and which can't/shouldn't.

And here we come to the reason for the mail - we need help with this filtering. This is a job that anyone can do, and a few minutes of your time will allow other people a few minutes more implementing the features wanted before the freeze. What do you need to do? Well, go to http://bugzilla.gnome.org, click on the "Open a new bugzilla account" link, enter a valid e-mail, and you will receive a mail from bugzilla containing your password, and the link where you can log in.

Once you are logged in, click on this link... http://makeashorterlink.com/?S1DF64A55 ... which will take you to a list of all bugs which currently have the milestone "--" (that is, bugs which are not targetted for any release). And click on one.

On the bug page, there is a drop-down box called "Milestone". The milestone of every bug should be set, and the milestone of every bug with the "--" milestone should be set to future, 2.0 or 1.3.x.

The idea of the feature freeze is to be very brutal with these bugs. Of the 361 bugs above, 221 are enhancement requests (feature improvements). Each of these needs to be ranked in terms of importance and needs to get targetted for a future release, or closed.

This is a very simple job for any given bug. As an example, bug #101256 (Improve color blindness filters), the functionality has been implemented, but has not quite been perfected. Change milestone to Future - this is not a feature which will block a stable release.

The only problem is that there are so many bugs to do. So here is your chance to give a little time to the gimp, and get a warm fuzzy feeling.

Guidelines for setting milestones:

1) Any bug does not block the feature freeze and should have its target milestone set to 2.0

2) Any enhancement which is not important gets milestone Future (where important is something which someone might consider crucial).

3) Important features should be milestoned 1.3.x.

The problem comes with what's considered important or not. But don't get too worked up about it. 20 or 30 people receive an e-mail when a bug is changed, so that if you make a change with which someone disagrees strongly, they will let you know through bugzilla.

Once this first filter is done, we will then start cutting more of the enhancement requests. If you see an enhancement and you're not sure if it's crucial or not, it isn't. Put it in Future.

I really cannot overstate how much this will help us get on track for a 2.0 release soon. The second stage in the Great Enhancement Chop is to try to associate enhancements with the people who are going to code them. If no-one is going to code an enhancement, it gets cut. This is really quite easy when you get the hang of it :)

So, there we go. Could people who are interested in doing this reply, just so I know what the take-up is like? Thanks a lot,

Cheers, and happy gimping, Dave.