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
>