maria-developers team mailing list archive

[James Briggs <james.briggs@xxxxxxxxx>]

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 <elenst@xxxxxxxxxxxxxxxx> wrote:

> From: Elena Stepanova <elenst@xxxxxxxxxxxxxxxx>
> Subject: Re: [Maria-developers] Process suggestion for minor issues
> To: "Sergei Golubchik" <serg@xxxxxxxxxxx>
> Cc: maria-developers@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp
>