On Tue, 2004-11-23 at 15:58 -0500, Morten Welinder wrote: > I think you are optimizing the wrong thing here. > > I *like* bumping the target to be painful! That pain is -- as you > note -- an indication that too many bugs are on a release's target. > I don't think the cause is that too many bugs get put there, but > more like that too few bugs on the target list get fixed. Take a good look at what is on the 2.4.14 milestone. Many of the things on there *can't* be fixed because they are portability problems to obscure platforms. Other things on there simply don't matter compared to more important issue. > In other words, it's sexy to work on new features, but work-avoidance > sets in when it comes to cleaning out old muck. I think this is an unrealistic view; unless you consider the end goal of the GTK+ project is to reduce the total number of bugs in bugzilla and nothing else, sometimes new features (sexy, or not) *should* take precedence over trivial bugs. > Take 132311, for example. It's had a very simple patch for a year > and has been bumped so many times that it fell off at some point. What I want is that when something gets put on 2.4.14 (because it has a patch) we actually notice that we need to fix it. That particular bug, well, it's not blocking on "just being applied", it's blocking because Jonathan suspects that it will cause subtle breakage and thinks it needs more detailed analysis. So, the right thing forward is to talk to jrb (at a #gtk-devel meeting say) and say "what do we need to do to make you comfortable with this bug". Once you agreed on that, you could put the bug on the next milestone. We shouldn't have stuff on a milestone unless we have a concrete course of action and person assigned to make sure it gets fixed. > But if you really wanted to reduce the bug spam, just add milestones > "2.4 series" and "2.5 series" for bugs not blocking any particular > release in someone's mind. Anything with a finer scale than that > is better handled by keywords like "easy-fix" and dependencies like > "block by bug 123456". Most of the minor fixes that get bumped along aren't '2.4 series', they are 'would be possible to fix in 2.4'. But in the absence of infinite amounts of time suddenly showing up on my doorstep, would you rather have me working on say bug 145243, a bug with an obscure feature of GTK+ DND that occurs on 'pwm'. Or, say, on rotated text in GDK. I think we need a milestone system that reflects the work process we actually do. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part