From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org,
openembedded-architecture@lists.openembedded.org,
openembedded-devel@lists.openembedded.org
Subject: Re: Patchwork & patch handling improvements
Date: Tue, 1 Dec 2015 11:47:20 +0100 [thread overview]
Message-ID: <20151201104720.GB2251@jama> (raw)
In-Reply-To: <41399562.aYmIK0zX5I@peggleto-mobl.ger.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]
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.
Regards,
> > Instead of cross-posting, maybe this would be a good email for the new
> > architecture list (CC'ed)?
>
> Perhaps yes; I'm a bit concerned that list still doesn't have that many
> subscribers though (currently 28, two of which are the same person).
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]
next prev parent reply other threads:[~2015-12-01 10:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-26 21:00 Patchwork & patch handling improvements Paul Eggleton
2015-11-26 21:12 ` Burton, Ross
2015-11-27 17:15 ` akuster808
2015-11-29 20:06 ` Paul Eggleton
2015-11-30 13:56 ` Koen Kooi
2015-11-30 15:19 ` Trevor Woerner
2015-11-30 18:49 ` Paul Eggleton
2015-12-01 10:47 ` Martin Jansa [this message]
2015-12-02 3:01 ` Paul Eggleton
2015-12-02 8:17 ` Martin Jansa
2015-12-02 10:54 ` Barros Pena, Belen
2015-12-02 10:59 ` Barros Pena, Belen
2015-12-02 18:04 ` Martin Jansa
2015-12-02 18:43 ` [Openembedded-architecture] " Burton, Ross
2015-12-02 21:58 ` Tim Orling
2015-12-03 11:43 ` Barros Pena, Belen
2015-12-03 12:51 ` Burton, Ross
2015-12-03 14:05 ` Martin Jansa
2015-12-03 14:43 ` Barros Pena, Belen
2015-12-03 11:38 ` Barros Pena, Belen
2015-12-02 8:44 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151201104720.GB2251@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=paul.eggleton@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox