Hi folks. 1) I like the idea of using wontfix for issues that don't make sense to fix, and wishlist for issues that don't have time to fix now.
2) wishlist items would be a good starting point for new contributors to work on. Kind of like "linux kernel janitors", but without the fail, hopefully. Thanks, James. --- On Fri, 6/14/13, Elena Stepanova <ele...@montyprogram.com> wrote: > From: Elena Stepanova <ele...@montyprogram.com> > Subject: Re: [Maria-developers] Process suggestion for minor issues > To: "Sergei Golubchik" <s...@mariadb.org> > Cc: maria-developers@lists.launchpad.net > Date: Friday, June 14, 2013, 9:32 AM > (warning: it's a long one) > > Hi Sergei, > > On 6/14/2013 6:26 PM, Sergei Golubchik wrote: > > Hi, Elena! > > > > On Jun 14, Elena Stepanova wrote: > >> On 6/14/2013 2:27 PM, Rasmus Johansson wrote: > >>> Here is a suggested process to handle the ever > growing amount of > >>> minors. If a minor issue isn't fixed after two > consecutive releases > >>> it's re-reviewed and either priority changed to > major (or higher), > >>> or the minor issue is closed with resolution > Won't Fix and a > >>> comment. Example of comment can be that > "this is an edge case where > >>> effort and benefits doesn't correlate". > >> > >> I don't think the algorithm is quite fair. It means > that if a really > >> minor bug happens to be found during a relatively > slow period, it gets > >> fixed, but another bug, even considerably more > important (but still > >> falling into "not major => minor" category), can > be by this time closed > >> as "not worth fixing" just because people had been > busy with some other > >> stuff and couldn't fix it over two previous > releases; while logically, > >> if somebody suddenly has time to fix a minor bug, > the latter should be > >> fixed first. > > > > This algorithm has a "re-reviewed and either priority > changed to > > major..." step, so it's not just the timing. Not like > automatic closing > > of old bugs. > > Yes, I got that part; but it doesn't change the potential > faulty result. > > Lets say we have imaginary priorities 1-5 which are all > "minor", 1 being the lowest. > > For a while you had had a bug of "priority 4". After 2 > releases the reviewing force reviewed it, decided it was > minor (rightly so), and closed it. > A few days later you got a bug of "priority 1". > A few more days later you suddenly have time to fix a bug -- > you are stuck at your main task and need a distraction, or > you've got a headache and can't work on anything serious, or > you only have half an hour before you need to go pick up > kids... whatever. Naturally, you go to the list of your open > bugs, take a quick look and pick whatever fits. If you still > had the bug of priority 4, you'd fix it now, but instead you > fix the bug of priority 1. > > I don't know about others, but I do keep a bunch of open > low-priority tasks, and while rarely, sometimes it happens > that I can do something about a minor one. And then I look > at them and pick by importance and "suitability for the > moment", not by the creation time. > > > > >> I'm fine with closing bugs as "Won't Fix", but imho > it should be based > >> on the merits of the bug itself, not on the bad > timing of its > >> creation. Since all our developers are very > senior and can totally > >> make such a decision on their own, I suppose anyone > who a bug is > >> assigned to can take a look at it and either close > it as "Won't fix" > >> with a proper explanation, regardless the timing > (even right after > >> receiving it), or keep it open. > > > > The main issue I didn't like - what that algorithm is > making an attempt > > of solving - is a growing pile of minor bugs that we > aren't going to > > fix. > > I agree, there is no point at keeping those that we are > really not going to fix. But I don't see anything critically > bad at preserving those that we *want* to fix, just > currently don't have time to -- as long as we don't schedule > them for the closest release, thus lying to users and to > ourselves (more on that later). > > I also think it's two essentially different categories. > Later here you are saying that "a closed bug can always be > reopened later and fixed". If we put the "don't have > resources to fix" bugs into the same trash bin as we > currently use for "really won't fix" bugs, re-opening will > never happen. Who will go through the whole bunch of "Won't > fix" bugs, review them *again* and see if they are really > not worth fixing, or if we had to close them because we > didn't have resources? Certainly you can't do it when you > just have little time to fix one-two small bugs, you'll > spend more time searching. > > > > > A bug is real, so it's difficult to say "won't fix", > it's much easier, > > psychologically, to say, "okay, I'll fix it, *when I > have time*". But > > really, for minor bugs this might never happen. > > But sooner or later somebody who's reviewing them will dare > close it anyway?.. > > Okay, I agree that psychologically it is easier to reject a > bug *together with somebody* than make such a decision on > your own, group mentality and all that, I get it and have it > myself; so if it's all about having some kind of committee > for closing such bugs, let it be. > > (I don't really know who could this committee consist of. > Generally, I'm a big supporter of a triage team, it makes > the process less personal. But in a company where everyone > is pretty much unique in his area, it's a bit strange, > because at the end only the expert can bring in an educated > verdict -- and this would normally be the person the bug is > already assigned to anyway; others will just be there to > hold his hand.) > > > And de-facto this leads to wrong expectations (users > believe the bug > > will be fixed in a specific version, but it isn't) and > us lying to our > > users. > > True, but I think the new approach will mess up more than it > will fix. > > Now we have Fix version evolution like that: > 5.5.30 => 5.5.31 => 5.5.32 => 5.5.33 => .... > It's bad. I still think that we shouldn't schedule minor > bugs for any particular version. We've discussed it before, > and yes, I know that we do it to keep them on somebody's > radar, but I would think that having it assigned to somebody > should be enough, since it's already on a radar of the > person who it's assigned to. But maybe I'm wrong and nobody > looks at lists of bugs assigned to them -- shouldn't we try > to change it instead, then? > > But with the new system, we will have > 5.5.30 => 5.5.31 => "Won't fix, it isn't worth it". > > If I were a user, now I'd be mad. If it isn't worth fixing, > why didn't you say so right away? Why schedule it and even > move it to the next release then? That's even more of lying > to users than we currently do, and in a more irritating > way. > > > > My idea is to be honest about it, and if we don't have > resources to fix > > a specific bug, we won't drag it forever from one > release to another, > > but close it eventually. > > I agree. But I think we shouldn't even start dragging it > then. > If you are going to have a committee which would regularly > review bugs (those that have waited for 2 releases) and > decide if they're worth fixing or not, why not do it right > away -- let the same committee decide it for *new* bugs > instead, so that unimportant ones don't even get scheduled > and go to the trash bin immediately. It will spare users > wrong expectations. > > > > And yes, I hate closing non-fixed bugs too. > > > > If you can suggest another solution, please do. But > "keep it open" > > doesn't work, as we've seen already. > > Well, I'd suggest to consider adjusting yours a little, in > the following way: > > - define who will be reviewing the bugs; > - those person(s) will screen new bugs instead of those that > have waited for 2 releases; > - , set "Won't fix" when we really mean it (example: PBXT > bugs, etc.), and create a new resolution "Don't have time to > fix" or "Wishlist" or whatever, and put corresponding bugs > there, while keeping them assigned. > > The last point is to preserve at least hypothetical > possibility for the bugs to be re-opened later. > > So, if somebody has time to fix a minor bug, first he looks > at the list of his open bugs (we already know that the > committee kept only most worthy ones there). If nothing fits > the moment, or (a miracle!) the list is empty, the somebody > goes to the "wishlist" bugs assigned to him, and picks from > there. At the same time, those bugs aren't shown as open, > aren't scheduled for any particular release, the users > aren't misled, etc. > > > A couple more notes: > - I think external bugs should generally have higher > priority than otherwise equal ones found internally; > - a different approach might be needed for bugs in new > feature trees, it should be decided separately (the basic > question is -- when we consider the feature good enough to > be pushed to the main tree, whether it requires fixing minor > bugs or not). > > > /E > > > > > Besides, a closed bug can always be reopened later and > fixed. > > > > > > Regards, > > Sergei > > > > _______________________________________________ > Mailing list: https://launchpad.net/~maria-developers > Post to : maria-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~maria-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
