[OE-core] Patchwork & patch handling improvements

[Richard Purdie]

On Mon, 2015-11-30 at 10:19 -0500, Trevor Woerner wrote:
> On 11/26/15 16:00, Paul Eggleton wrote:
> > I'm also 
> > trying to ensure that the patch validation is generic enough so it can live in 
> > OE-Core, and thus we can easily update and refine it over time in line with the 
> > code itself as well as encourage submitters to use the script on their own 
> > changes before sending.
> 
> This all sounds like an improvement and is therefore a step in the right
> direction :-)
> 
> A while back I had the idea of "porting" the kernel's "checkpatch.pl" to
> The Yocto Project (it was around the same time that I was trying to
> float the whole "Maintainers File" idea too, since I was also trying to
> re-purpose "get-maintainer.pl" as well). About one minute into that
> effort I realized the existing *.bb files were all over the place in
> terms of the order of statements and the order of the blocks of
> statements. At that time I found one recipe style guide from OE, and
> another one from The Yocto Project, each of which described a slightly
> different preference. So I asked on the mailing list and quickly
> discovered that both groups prefer a different style.
> 
> I'm not saying this job isn't worth doing, but I am pointing out there's
> the potential for feathers to be ruffled on both sides if someone tries
> to produce a definitive style guide for recipe files and then enforces
> it in an automated way. Since it is the OpenEmbedded Project's job to
> provide the recipes for The Yocto Project, I'm guessing this question
> needs to be decided by them? If that sounds reasonable, then maybe The
> Yocto Project needs to acquiesce to OE's decision?
> 
> Instead of cross-posting, maybe this would be a good email for the new
> architecture list (CC'ed)?

I think the areas where there are disagreements are comparatively small,
really just on shell whitespace. Where they do exist, they are
problematic, not least as some layers effectively ignored an agreement
made by the TSC simply because they didn't agree with it. It basically
means the OE TSC only applies to OE-Core as far as I can tell, which is
sad but is the decision that was made. This also means the TSC has no
real influence over any proposed coding style being used outside
OE-Core.

I do still believe shell whitespace changes would cause significant
patch compatibility issues, I know I disagree on Martin over that. I
still don't like the idea of people blindly running a formatting script
since we'll than start seeing patches every time there is a single space
in the wrong place. We simply don't want that amount of churn on the
metadata.

I can imagine several people replying and saying that patch churn is not
an issue but having seen the things people send patches for, I believe
it will be. I don't want to encourage such things as I believe there are
better things to do with our time (mine included as I'd have to review
them, even to just say 'no').

The maintainers file is a different problem and its one of maintenance,
and more specifically what being listed means, who can be listed, how
that listing can be changed and so on. The Yocto Project has some notion
of maintainer and there its easy, Ross and I can made decisions on who
is listed and what those people are expected to do and we can make it
work (its how we ensure things get upgraded with some regularity). For
OE, who would do this and what would the maintainer file mean? If
someone patches something, are they required to cc the maintainer on
patches for example? (that would imply workflow overhead) What if they
don't cc a maintainer? Should we be forced to revert such a patch?

In many ways its like the "what is a stable branch?" question. Some
people want to use a maintainers file as a way of having a veto on
certain patches. Others want to use it as a way of finding people to fix
bugs. Others again want it to help review patches. The uses vary and you
need a clear definition about what its being used for to make it work.

If someone wants to put together a proposal about which problem this
solves, with clear definitions/charter about how it would all work,
great, but I've seen a lot of problems with such files and I worry it
creates more problems than it would solve.

Cheers,

Richard