[coreboot] Changes to the coreboot Project Structure

[Stefan Reinauer]

Hi folks,

ok, sorry to those who thought that I was missing in action. It feels
good to have a weekend to get out into the sun every now and then, and
let the dust settle a little bit in a maybe too heated discussion.

I will address your concerns.

* mrnuke <mr.nuke.me at gmail.com> [140320 23:42]:
> On Thursday, March 20, 2014 10:55:57 PM Stefan Reinauer wrote:
> > * Build a MAINTAINERS file for common code, and encourage people to keep
> >   subsystem maintainers in the loop for changes
> >   [...]
> >
> This is somewhat what linux does, and it works well for them.
 
When we (Ron, Marc, Patrick, Peter, Aaron and I) wrote up the document,
we tried to introduce some of the Linux kernel habits that might work
well for us.

> Might be a little OT/irrelevant, but why not make gerrit need a "maintainer 
> must approve" before making the change submittable.

Yes, that would be a great way of implementing this.

> > * Look into making gerrit automatically add reviewers based on maintainer
> >   lists
> >   [...]
> > 
> Can we find something better than gerrit? I think gerrit encourages too much 
> bikeshedding. It also encourages people to filter out gerrit emails, so that 
> any such maintainers would not "get the message".

This has come up before and we should consider that option.

Gerrit is very convenient because it never loses a patch. Our mailing
list based approach in previous years was way less reliable. Also, the
integration of jenkins is very convenient. There might be other
solutions that have both of these advantages.

> > * Import previous code reviews and results
> >   The tree major stakeholders in the project all own internal code review
> >   systems, some of which are public (e.g. the Google Chrome OS repository)
> >   and have code reviews that include representatives outside of Google to
> >   ensure general code quality and making sure the improvements made for
> >   products don’t negatively impact upstreamability. For those cases it
> >   would be extremely helpful to honor the code reviews already done in the
> >   upstream repository
> > 
> >   Status: TO BE INVESTIGATED
> > 
> I couldn't disagree more. First of all, the idea of "representatives outside 
> of <company> to ensure general code quality" is contrary to the idea of 
> allowing the community to scrutinize to-be-upstreamed contributions. When you 
> combine that with the idea of [blindly] honoring code reviews already done 
> upstream, you have effectively eliminated the scrutiny and review from the 
> community.

When rebasing to a new coreboot version, e.g. the Chromium OS project
does [blindly] honor code reviews already done upstream. On the
contrary, I think that this strengthens the community instead of
eliminating its reviews.

> I've seen mostly cases of great external reviews, but have also 
> seen a fair share of bodged, nonsensical ones where terrible patches have been 
> accepted without much thought.
> 
> If the community has to accept code reviews done under closed doors, these 
> contributions are effectively code dumps. I do not remember this ever being 
> beneficial to the community, and usually results in the community needing to 
> clean up afterwards. See linux for details.

These reviews are not happening under closed doors. The Chromium OS
project is open source and completely transparent in that manner. 

> What do we need to do to allow commercial contributors to work directly 
> upstream? And before you discount this question for menial technical reasons, 
> please take a moment to keep this conversation open, and let's try to find an 
> answer. Will it work for 100% of commercial contributors? No. However, this 
> should be the preferred method for upstreaming contributions. See linux for an 
> explanation why this works best.

The intent of these suggestions is to move the non-commercial and
commercial contributors in the community closer together. One example is
the board ownership that would prevent people from "messing with other
people's boards" without their consent.

Also, if you are keeping an eye on both the Chromium OS coreboot tree
and the upstream coreboot tree you will notice that basically all
structural changes land in the upstream tree first, whereas the only
thing that ends up in the Chromium OS tree first is code supporting
specific components.

This has proven to be somewhat successful as it keeps the person working
at three a clock in the morning to ship a product under a tough deadline
from going crazy because the target keeps moving under him.

This is not a bad thing at all. It's the separation of feature
development and product development, in a way. Google even does this for
each of the Chrome OS devices, internally (as you can see in the Chromium OS
repository) At some point there's a branch of the Chromium OS "top of
tree" coreboot used as the basis for further product development and no
new features go into that product branch (e.g. firmware branch) unless
needed and carefully selected.

> I am sorry to say this Stefan, but, in my opinion, you would not make a good 
> "benevolent dictator".
> 
> Over the past years, I have found you to be extremely biased towards the needs 
> of the commercial developers, whilst being less interested and attentive to 
> the needs and wished of the non-commercial part of the community. I do not 
> believe that someone biased towards one part or another of the community can 
> make a great leader. You also, on some occasions, delayed good NC 
> contributions in order to merge less-than-ideal commercial contributions, 
> which later had to be cleaned up by the NC guys.
> 
> You are a great person, but I believe that having you as the leader, we would 
> have a "benevolent dictator" for the commercial contributors, where the non-
> commercial ones would see have a mere "dictator".
> 
> On the other hand, I have found Ron Minnich to be very unbiased and equally 
> receptive to ideas from both sides of the community. While I am certain some 
> people might come to point out mistakes Ron had done in the past, unlike you, 
> I did not find a pattern of bias in them. I think Ron is the best candidate 
> for the role of "President and Benevolent Dictator of Coreboot".

I have functioned as the BD of this project for the last 7 years
now, and it has worked just fine in my opinion - and I think many others
share this opinion. In fact it seems I was so benevolent that you didn't
even notice the fact. ;-)

Those who have been with the project for a long time know that I am not
the corporate shill you describe me as in your mails. Among many other
things I have paid for the infrastructure running the coreboot project
out of my private pocket since 2004, despite many offers from corporate
entities to throw the few bucks over the fence. Why? Because coreboot as
a project needs to be independent.

I have also worked on Open Source firmware ever since I started OpenBIOS
in '97. Mind you, at that time Google didn't even exist.

If you like, we can share more thoughts and expiriences on that. 

> It has been this way for years, so to speak. I also find you to be a much 
> better candidate as the representative/maintainer for Google contributions. I 
> think you can do much more good to coreboot in this position.

Thank you for your kind words. It's appreciated. I'm fine with having
more than a single role, always have been since I joined the project
more then a decade ago. 

All the best,

Stefan