Possibly an appendix defining coreboot leadership would help.
On Fri, Oct 30, 2015 at 9:51 AM Martin Roth gaumless@gmail.com wrote:
Hi Alex, Thanks for voicing your concerns. I do think that most of the issues you bring up are handled, or aren't as big issues you make them out to be. As always, I could be wrong, so I'd again invite others to give their opinions. I've tried to address your issues below.
... the "maintainer" is given almost absolute veto power in all matters relating to that code.
...
There are also no responsibilities defined for a "maintainer", despite such person being given near-inter-stellar of power.
I did try to define maintainers in the document:
- Try to coordinate with platform maintainers when making changes to platforms. The platform maintainers are the users who initially pushed
the code for that platform, as well as users who have made significant changes to a platform. To find out who maintains a piece of code, please use util/scripts/maintainers.go or refer to the original author of the code in git log. I'm not certain how "Try to coordinate" is being read as "almost absolute veto power" or "near-inter-stellar of power".
Concerns from external reviewers often get ignored or brushed off as "don't care".
This is absolutely addressed by these three guidelines:
- Respond to anyone who has taken the time to review your patches.
- If there have been comments or discussion on a patch, verify that the comments have been addressed before giving a +2.
- If there is still ongoing discussion to a patch, try to wait for a
conclusion to the discussion before submitting it to the tree.
I've seen plenty of cases where patches have been -2'd by W@g.com until other @g.com patches were merged, only for the -2 to be removed once it was on the contributor to rebase his work.
I haven't seen this, but if you see a situation where you feel like someone is being treated unfairly, please bring it to the attention of the coreboot leadership or post something to the mailing list.
This then creates another significant issue: the bar for contributions from such teams is very low, while anyone else experiences a much higher bar. This has many times resulted in sub-optimal code being merged, and great contributions getting delayed and abandoned.
Again, I feel like if you comment on these patches, the rules above should handle these issues. And again, if you feel like something is unfair, bring attention to it.
... Raptor Eng. was asking around $15000 to upstream ... All of a sudden, we've made coreboot a very expensive project to support.
Additionally, I specifically reached out to tpearson with these guidelines to get his feedback before they were posted. I have tried to address the concerns he brought up. If you (or anyone else) feel like there's something specific we can add here that will help him or future developers get code submitted, please recommend the addition.
Then there's talk about a vague "coreboot leadership"...
Patrick addressed this in the review - here's Stefan talking about coreboot leadership: http://blogs.coreboot.org/blog/2015/05/11/on-coreboot-leadership/
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot