Xserver driver merging pros & cons

[Jeremy Huddleston]

On Sep 19, 2011, at 00:00, Peter Hutterer wrote:

>> If the reason the model doesn't work is because people don't review, then
>> some how getting people to step up and give reviews would fix the model.
> 
> I think the one thing we don't cover right now are patches that cannot
> really be reviewed by anyone but the author. Are they left to linger or will 
> they be pulled regardless? IIRC I've gotten patches into the tree with
> little or no review after pestering keith for a bit but those patches are
> still quite slow to go in.
> 
> I believe most of your changes go in mostly unreviewed, mostly so because
> your subsystem affects hardly any other upstream developers. Simply spelling
> that out may alraedy be a step towards a better process.

True that it may be hard to get reviews, but I'd be happy with Tested-by if reviews are hard to come by for something.  Mentioning which branch to pull in the 00/XX email would be useful for testers.

>>> My point is, for drivers, that review system will slow
>>> things down (because you need to wait for a pull from someone who has
>>> no familiarity with your code)
>> 
>> No you don't.  The code is already in your tree?  Why do you need to wait
>> for it to land on master?  Why do you CARE when it lands on master?  The
>> only people who care when it lands on master are release managers and
>> distributions.  Driver developers won't even be using master, they'll be
>> using their branch off of master.
> 
> if you're working on a bug, you can't close the bug until the patch lands on
> master. if that is delayed by review delays, pull delays and then
> cherry-pick + pull to stable delays, it can be quite annoying (more
> bugreporter comments, more duplicates, remembering to close the bug, etc).

If Bugzilla overhead is part of the problem, we can address that ... I'd be fine closing the bug when it lands "somewhere" ... just comment with "this bug is fixed in xserver-ati/master and we expect it will land in xserver/master before the xorg-server-1.11.99.1 tag."  If it should be cherry-picked into stable, assign the bug to the stable release manager with a comment to such rather than closing.  That should have no additional overhead than is there currently and it puts the responsibility on the release manager to get the change pulled in to stable.