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@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