On 02/07/11 14:00, ext Robin Burchell wrote: > Hi, > > On 07/02/11 14:26, Kristian Amlie wrote: >>> On 07/02/11 11:20, Kristian Amlie wrote: >>>> - "W19 - Abandon review - 3" - Is this basically to close a review after >>>> there has been no activity or it has been rejected? If I understand >>>> correctly what this is, I would give it 5, since without this the view >>>> of active reviews will be cluttered with old junk (basically what we >>>> have with merge requests today). >>> >>> AFAIK, There is nothing stopping merge requests from being closed, >>> except people actually going through and closing them. >> >> Hmm, maybe merge requests was a bad example. Basically what I meant was: >> >> - Ability to close reviews, even if they are not completed (because they >> are old / irrelevant / etc): 5 - Mandatory >> - Autoclosing reviews. Does not have to be fully automatic, but has to >> be possible to do in bulk operations, otherwise we get flooded with old >> junk: 5 - Mandatory > > I'm a little confused about what exactly you mean by a 'review'. If you > mean a *comment* on a merge request, then I guess that ties in with > 'review a specific revision of a contribution', perhaps. Reviews of > previous revisions should perhaps be archived - but still available - in > an ideal world.
Sorry, by review I basically mean merge request, yes. > If you're meaning a merge request, then I'd agree with the ability to > close them, but disagree with your reasoning (they should be dealt with > *before* they become old) and definitely not in bulk - because they > should be dealt with in time. Of course I agree that we should not aim for leaving merge requests to rot, but in the real world, it happens. Instead of a acquiring a long tail of very old requests that probably don't even apply anymore, we need to have a way to remove them efficiently. But in the worst case, this is still a future problem, so maybe it's not so important to have the priority set to 5. I will say that it can be a 3 - Should have. The ability to close single merge requests still needs to be 5 though, IMO. > There should never be a situation with a well maintained system similar > to the current one with 4 pages of open merge requests. If everyone is > having to use this system on a daily basis in order to get their changes > in, then I'd be willing to bet it will be forced to stay clean, because > everyone will have the same pain to suffer if it isn't, not just people > who don't happen to have push permissions. I'm not so convinced it will be solved by itself that easily, but maybe I'm just a pessimist! ;-) -- Kristian _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
