From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-devel@lists.openembedded.org,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [oe] OpenEmbedded TSC 8 April 2013
Date: Wed, 24 Apr 2013 10:22:59 +0200 [thread overview]
Message-ID: <20130424082259.GF3217@jama> (raw)
In-Reply-To: <1366790466.23738.86.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Wed, Apr 24, 2013 at 09:01:06AM +0100, Richard Purdie wrote:
> On Wed, 2013-04-24 at 08:43 +0200, Martin Jansa wrote:
> > On Tue, Apr 23, 2013 at 02:47:56PM -0700, Jeff Osier-Mixon wrote:
> > > OpenEmbedded Technical Steering Committee
> > > 8 April 2013
> > >
> > > b. document whitespace changes to the shell
> > > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> > > http://www.openembedded.org/wiki/Styleguide
> > > https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide
> > > => still need to de-dup these, need a volunteer
> > > ask for volunteers after 1.4 (jefro)
> >
> > Someone probably noticed, but all meta-openembedded layers are now using
> > consistent indentation:
> > http://git.openembedded.org/meta-openembedded/commit/?id=a45830a39bb47a9eab27980d52966226c9504ea4
> >
> > Can we reevaluate decision to keep styleguide promoting different
> > indentation for python and shell tasks? Otherwise we should mention
> > different rules for oe-core and other layers.
>
> The TSC talked about it and agreed a particular direction. Its clear
> that some people don't like the direction so they just ignored it and do
> their own thing anyway.
>
> This is the wrong way to go about making decisions and I'm extremely
> disappointed people are doing this.
>
> There were specific technical reasons I suggested we not do this. One of
> the asks of the Yocto members is some kind of stability, whatever that
> is. Whitespace changes like this are *extremely* disruptive to patch
> flow. I think its clear there are people out there using older versions
> of the codebase yet they pick patches off master and backport them for a
> variety of reasons. As soon as you get changes like this involved, it
> breaks their ability to do that. With the python change, there was a
> good technical reason we did it. Despite that I was personally literally
> backed into a corner and shouted at by some rather upset people last
> time this happened with the python change. I can see their point too.
> For changing shell, we don't have any good technical reason other than
> cosmetics. I've made this argument before.
Hi,
I'm sorry you feel that way about it, I'll try to make it a bit better:
1) it was discussed and acked by major meta-openembedded contributors
and maintainers:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-April/044989.html
2) it was done just before we'll branch dylan, so that backporting issue
is only for people backporting over 2 releases (from after-dylan-master
to danny). And even if someone gets whitespace wrong in backport, then
there is no real harm, because as you say, it's only cosmetic now and
meta-openembedded layers were very inconsistent about it (tabs were used
only in minority of recipes).
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-devel@lists.openembedded.org,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] OpenEmbedded TSC 8 April 2013
Date: Wed, 24 Apr 2013 10:22:59 +0200 [thread overview]
Message-ID: <20130424082259.GF3217@jama> (raw)
In-Reply-To: <1366790466.23738.86.camel@ted>
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Wed, Apr 24, 2013 at 09:01:06AM +0100, Richard Purdie wrote:
> On Wed, 2013-04-24 at 08:43 +0200, Martin Jansa wrote:
> > On Tue, Apr 23, 2013 at 02:47:56PM -0700, Jeff Osier-Mixon wrote:
> > > OpenEmbedded Technical Steering Committee
> > > 8 April 2013
> > >
> > > b. document whitespace changes to the shell
> > > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> > > http://www.openembedded.org/wiki/Styleguide
> > > https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide
> > > => still need to de-dup these, need a volunteer
> > > ask for volunteers after 1.4 (jefro)
> >
> > Someone probably noticed, but all meta-openembedded layers are now using
> > consistent indentation:
> > http://git.openembedded.org/meta-openembedded/commit/?id=a45830a39bb47a9eab27980d52966226c9504ea4
> >
> > Can we reevaluate decision to keep styleguide promoting different
> > indentation for python and shell tasks? Otherwise we should mention
> > different rules for oe-core and other layers.
>
> The TSC talked about it and agreed a particular direction. Its clear
> that some people don't like the direction so they just ignored it and do
> their own thing anyway.
>
> This is the wrong way to go about making decisions and I'm extremely
> disappointed people are doing this.
>
> There were specific technical reasons I suggested we not do this. One of
> the asks of the Yocto members is some kind of stability, whatever that
> is. Whitespace changes like this are *extremely* disruptive to patch
> flow. I think its clear there are people out there using older versions
> of the codebase yet they pick patches off master and backport them for a
> variety of reasons. As soon as you get changes like this involved, it
> breaks their ability to do that. With the python change, there was a
> good technical reason we did it. Despite that I was personally literally
> backed into a corner and shouted at by some rather upset people last
> time this happened with the python change. I can see their point too.
> For changing shell, we don't have any good technical reason other than
> cosmetics. I've made this argument before.
Hi,
I'm sorry you feel that way about it, I'll try to make it a bit better:
1) it was discussed and acked by major meta-openembedded contributors
and maintainers:
http://lists.linuxtogo.org/pipermail/openembedded-devel/2013-April/044989.html
2) it was done just before we'll branch dylan, so that backporting issue
is only for people backporting over 2 releases (from after-dylan-master
to danny). And even if someone gets whitespace wrong in backport, then
there is no real harm, because as you say, it's only cosmetic now and
meta-openembedded layers were very inconsistent about it (tabs were used
only in minority of recipes).
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
next prev parent reply other threads:[~2013-04-24 8:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 21:47 OpenEmbedded TSC 8 April 2013 Jeff Osier-Mixon
2013-04-24 6:43 ` [oe] " Martin Jansa
2013-04-24 6:43 ` Martin Jansa
2013-04-24 8:01 ` [oe] " Richard Purdie
2013-04-24 8:01 ` [OE-core] " Richard Purdie
2013-04-24 8:22 ` Martin Jansa [this message]
2013-04-24 8:22 ` Martin Jansa
2013-04-24 10:39 ` [oe] " Phil Blundell
2013-04-24 12:31 ` Richard Purdie
2013-04-24 12:31 ` [OE-core] " 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=20130424082259.GF3217@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.