On 23 May 2012 06:34, Peter Hutterer <peter.hutte...@who-t.net> wrote: > On 18/05/12 21:17 , Michal Suchanek wrote: >> >> On 18 May 2012 12:40, Peter Hutterer<peter.hutte...@who-t.net> wrote: >>> >>> On 18/05/12 19:26 , Michal Suchanek wrote: >>>> >>>> >>>> On 18 May 2012 01:14, Peter Hutterer<peter.hutte...@who-t.net> wrote: >>>>> >>>>> >>>>> On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> (sorry for jumping in from the outside and breaking the thread!) >>>>>> >>>>>> I read about this problem and wanted to offer a suggestion! >>>>>> >>>>>> What if you set up a Gerrit server for git.freedesktop.org? That's the >>>>>> tool the Android OpenSource project uses among other things: >>>>>> https://android-review.googlesource.com/ >>>>>> Perhaps if it was easier to contribute to reviewing code, more people >>>>>> would do it more often? >>>>> >>>>> >>>>> >>>>>> It's also a very nice tool I have to say, I use it every day at work. >>>>>> It's easy to integrate with automatic >>>>>> testing of patchsets before they're submitted to the repository for >>>>>> example. >>>>> >>>>> >>>>> >>>>> tbh I doubt what we have is a tool problem. Patches are sent to the >>>>> list >>>>> and >>>>> can be reviewed quite easily there (for subscribers, anyway). The issue >>>>> we >>>>> have is manpower and, more importantly, manpower of people with enough >>>>> knowledge to judge whether a patchset has side-effects beyond the >>>>> obvious. >>>>> >>>>> in the end, such patches tend fall on the shoulders of a few and adding >>>>> another tool that they have to check will increase, not decrease, the >>>>> workload for those. >>>> >>>> >>>> >>>> tbh using a mailing list for that looks very impractical. >>>> >>>> - patches get missed completely >>> >>> >>> >>> true. we do encourage people to re-submit. which, aside from the obvious >>> disadvantage, has advantages too. I found the problem with any todo list >>> is >>> that sooner or later it becomes so long that you either have to wipe it >>> (by >>> switching to a different system sometimes) or you start ignoring stuff >>> anyway. >>> >>> given that one of the problems is reviewer bandwidth, I expect this to >>> happen with any new tool. patchwork was great in the first few weeks, now >>> it's a kitchensink great for getting URLs and not much else. >> >> >> Given that reviewer bandwidth is scarce it would be perhaps helpful to >> spare it by having a tool that presents all the not-yet-reviewed >> patches in one place rather than reviewers fishing for them in the >> mailing list or in the patchwork. > > > I believe that patchwork was supposed to be that tool, but either it's not > set up correctly or it just doesn't do that. I don't know but if patchwork > can do this, then this would be a simple immediate step. > > having said that - it can't be perfect without manual intervention - when > patches go through multiple revisions someone still has to mark them > manually as obsolete.
Well, gerrit is a BTS just like bugzilla except it it branch tracking system, not bug tracking system. So it likely has states for new, in-review, needs-update, obsolete, ... > > At several times in the past we noted the need for someone to just collect > leftover patches but that never happened, usually due to lack of > time. we really need someone to actually do it. That's something that a tracking system is supposed to do, be it patchwork or gerrit. > > >>>> - there is no track of what is related to what (as in the part of the >>>> same patchset or new revision of the same patchset) >>> >>> >>> >>> patch are usually in numbered series, in threads, with new revisinos >>> being >>> prefixed with "v2", "v3", etc. requires submitter discipline but it works >>> to >>> some degree. >> >> >> And as some of the patches get replies they get out of order and >> completely out of context. >> >>> >>> >>>> - you get a lots of list noise due to patches being sent one by one >>> >>> >>> >>> I'm not sure I follow this argument, can you expand? >> >> >> Like a series of 10+ patches for some part of the X server I do not >> understand landing on the list several times. >> >> I guess some people are fond of replying to the patches and quoting >> them in their email client and I can see that as nice feature but it's >> paid for by tons of list traffic. Necessarily large part of that is >> meaningless to most. >> >> The alternative is, of course, a link to git branch or something like >> that. > > > git branches are _incredibly_ painful to review. they're good for testing, > but the steps involved to point out an issue in a specific hunk of a > specific commit involves a lot more steps than just hitting reply and > starting to type. > Gerrit has an interface for that. Not sure how well it works since I never used gerrit extensively but it's obviously doable. Thanks Michal _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel