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 -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
