On Fri, May 18, 2012 at 1:17 PM, Michal Suchanek <hramr...@gmail.com> 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. > >> >> requiring people to ping when patches get missed at least notifies us which >> patches have people behind them that care. a feature that gets submitted >> once, forgotten and no-one pings for it may not have been that important to >> begin with. > > When you get the 5th patch for the same regression submitted the third > time it starts to look like shouting your patches off a cliff in the > dead of the night. > > >> >> >>> - 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. > > 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
I think that a tool that allows you to see diffs in a web interface and do point-and-click defect submission would never hurt. As long as it doesn't interfere with existing processes (too much). -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. _______________________________________________ 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
