Am Montag, den 27.02.2017, 13:32 -0800 schrieb Julius Werner:
> I don't think it's helpful to single out "corporate developers" as the
> black sheep that submit all the style violations. Every contributor, paid
> or hobby, new or long-time, needs to pay attention to the project
> guidelines equally. Everyone overlooks stuff some time, and it's normal
> especially for new contributors to not be quite that familiar with
> everything yet.
I certainly didn’t mean it that way. I didn’t want to single out anyone
as the black sheep. I apologize, if I offended anyone. I totally agree
with your view.
My focus on corporate developers was motivate by the following two
1. Corporate developers certainly contribute most of the commits and
2. I believe and assume corporations have *additional* ways to reach
> Its our responsibility as reviewers (especially those of us with +2
> rights) to educate them and make sure the rules are followed before a
> patch can get submitted.
> That said, I do agree that we have a lot of potential in making this easier
> and more consistent for everyone involved. I think the best tool for that
> is more automated checking... like that recent idea to make Jenkins add the
> checkpatch result visibly to its Verified+1 message.
> I'm not sure if the "where" of the guidelines really makes much of a
> difference... maybe we should just make them more discoverable either way?
> Could we put a big orange "please ensure that this patch conforms to the
> style guidelines at ..." banner in Gerrit somewhere near the submit button?
Most people push the commits from the command line I guess, so that –
especially in the beginning – they won’t even access the Web interface?
For corporations the following ideas came to my mind. The assumption is
that in corporations people are higher to see the colleagues in person
or to be in the same building.
1. In each division there is some kind of QA person “holding the hands”
for the first commit.
2. Before somebody starts working on coreboot there is a small
introduction by a colleague already familiar with the guidelines.
3. Do for example Intel, Google or Siemens have documents (tutorials,
videos, presentations) they could share? Would it make sense to
Regarding improving the documentation, I guess everyone agrees (and
nobody wants/likes to do it). In my opinion the easiest way would be to
copy as much as possible from other project (like the Linux kernel).
Though that should be discussed separately.