Re: [coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way

[mrnuke]

On Wednesday, March 26, 2014 03:32:12 PM Patrick Georgi wrote:
> Am Mittwoch, den 26.03.2014, 09:22 -0500 schrieb mrnuke:
> > Masters, of Gerrit, the pleasure of training gerrit to implement this
> > change is left entirely to you.
> 
> While we're specifying behaviour: what should happen to changes that
> affect multiple maintainer domains?
> 
Add each maintainer to the MMA list. A little clumsy? Yeah. On the other hand, 
it encourages splitting of patches in maintainer-domain chunks.

> (and before you say they shouldn't exist, refactorings regularily hit
> the entire tree)
> 
And that's one of the few cases where the above splitting may not be possible.

Alex

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way

[Patrick Georgi]

Am Mittwoch, den 26.03.2014, 09:22 -0500 schrieb mrnuke:
> Masters, of Gerrit, the pleasure of training gerrit to implement this change 
> is left entirely to you.
While we're specifying behaviour: what should happen to changes that
affect multiple maintainer domains?

(and before you say they shouldn't exist, refactorings regularily hit
the entire tree)


Patrick


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way

[mrnuke]

Not so long ago, Stefan announced some pretty drastic changes to the project 
structure. While I believe he wanted to discuss the direction and find a 
mutually agreeable direction, his email still raised the aneurysm level to 
over nine thousand.

So, how about we take the good ideas out of there and start putting them in 
practice. Today, I'll be focusing on the idea of MAINTAINERS. While it's nice 
to jump straight to maintainer trees, that's a long ways away, and I'm not 
even sure we reached consensus on it. Couple that with the changes needed to 
be done to _both_ gerrit configuration, _and_ gerrit workflow, this matter is 
better left for another day.

What we can do, however, is to start assigning maintainership of different 
sub-directories. Two ways to do it:
(i) One big MAINTARES file in top-level directory
(ii) One small MAINTAINER file in each directory with an assigned maintainer
Number (i) is human friendly, while (ii) is parser-friendly (I would hope). 

Now comes the fun part:
For directories with a maintainer, gerrit implements a MMA criteria. That's 
short for "Maintainer Must Approve". People are still welcome to do reviews, 
bikeshed, etc, but the maintainer has veto power. For directories without a 
maintainer, the old workflow applies (no MMA).

This should reduce confusion from conflicting reviews, and definitely reduce 
number of incidents where a patch gets merged with a review from a person who 
is not fully qualified to, well, do the review.

Masters, of Gerrit, the pleasure of training gerrit to implement this change 
is left entirely to you.

Alex

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot