On 18/05/12 19:26 , Michal Suchanek wrote:
On 18 May 2012 01:14, Peter Hutterer<[email protected]> 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.
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.
- 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.
- 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?
don't get me wrong, I don't think mailing lists is the ideal approach
but I haven't seen a better one. it is an old approach and many people
are well set up for the workflow so any new tool will have to have meet
quite a threshold there.
Cheers,
Peter
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
