On 02/12/2015 08:17, "openembedded-core-boun...@lists.openembedded.org on behalf of Martin Jansa" <openembedded-core-boun...@lists.openembedded.org on behalf of martin.ja...@gmail.com> wrote:
>On Wed, Dec 02, 2015 at 04:01:40PM +1300, Paul Eggleton wrote: >> On Tue, 01 Dec 2015 11:47:20 Martin Jansa wrote: >> > On Tue, Dec 01, 2015 at 07:49:50AM +1300, Paul Eggleton wrote: >> > > Hi Trevor, >> > > >> > > On Mon, 30 Nov 2015 10:19:35 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? >> > > >> > > I don't think there's that much of a division. I don't recall if it >>was >> > > you >> > > that raised it at the time but the issue of having two style guides >>did >> > > get >> > > rectified - I changed the one on the Yocto Project wiki to simply >>be a >> > > link to the OE style guide in June last year. It certainly didn't >>come >> > > about through a conscious decision to have a different style. >> > > >> > > However there is a minor disagreement over indentation for shell >>functions >> > > between OE-Core and other layers - this persists because of the >> > > backporting >> > > pain a blanket replacement would potentially lead to. As I recall >>this did >> > > get discussed at the OE TSC level. I think that's one thing we >>could just >> > > not evaluate (or make an option) until such time as we resolve the >> > > difference - and I do mean to see it resolved at some point in the >> > > future. >> > >> > Using consistent indentation (4 spaces) at least for new metadata >>would >> > be step in right direction. >> > >> > With the amount of changes which are backported to older releases I >> > still don't see this "backporting pain" argument. Doing it just before >> > the release is of course useful, because e.g. now more changes will be >> > backported to Jethro than to Fido or Dizzy. So having consistent >> > indentation in Jethro and master would prevent 95% of "backporting >> > pain". Maybe some Yocto 10.0 will finally get the meaning of >> > "consistent" indentation. >> >> I agree it's not ideal. I said above, I do want to see it resolved. >> >> Leaving indentation aside for a moment do you have any comments on my >> proposal? > >I'm not familiar with FDO fork, so I don't know how it looks and >behaves, This is how it looks like currently http://patchwork.freedesktop.org/project/intel-gfx/patches/ > but any improvement on patchwork side is definitely welcome and >I appreciate it. > >Does it support e.g. moving the patches to given bundle based on some >substring in subject? To sort e.g. meta-networking, meta-java, >meta-browser, .. patches automatically? Mmm, you might not like this, but we are thinking of getting rid of bundles. Basically, we assumed bundles were a manual way of creating patch series. The new Patchwork can identify series, so we thought: great! Bundles no longer needed. There are other features been considered that might be an alternative to bundles, like tagging > >I don't expect FDO fork to provide other features I'm used to from >gerrit like cherry-picking to selected branch from the UI or doing the >review there. But still if we're stuck with patchwork forever (because >some people hate gerrit), then any improvement is really appreciated, >thanks for looking into it. > >My only concern is about migrating current database, do you know if the >migration will keep the database including bundles as they are or do you >plan to set FDO version in parallel at least for some transition period? >Currently I have many patches in flight, because jenkins is running full >test-dependencies job for last 11 and based on progress it will take >14-21 more days to finish. > >Regards, > >-- >Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core