From: Martin Jansa <martin.jansa@gmail.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-devel@lists.openembedded.org,
openembedded-core@lists.openembedded.org
Subject: Re: [oe] OE TSC Minutes 7 May 2013
Date: Wed, 22 May 2013 17:19:50 +0200 [thread overview]
Message-ID: <20130522151950.GL32431@jama> (raw)
In-Reply-To: <3795534.7yd4ZVD7nC@helios>
[-- Attachment #1: Type: text/plain, Size: 3715 bytes --]
On Wed, May 22, 2013 at 04:11:02PM +0100, Paul Eggleton wrote:
> On Wednesday 22 May 2013 16:49:25 Martin Jansa wrote:
> > Using combination of tabs and spaces in the same file (and even on the
> > same lines) is quite bad, because it looks different based on tab length
> > and can show wrong indentation in case like 8 spaces and 2
> > 4-character-wide tabs on next line (where author was seeing 18 spaces on
> > 2nd line)
> >
> > It was acked by 2 TSC members:
> > Koen:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09016
> > 2.html Khem:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09020
> > 3.html
> >
> > 3rd member of TSC and maintainer of some meta-oe layers, was aware of this
> > change and wasn't complaining:
> > Paul:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09018
> > 4.html
>
> I didn't feel like I had good reason to object other than what had already
> been discussed. That should not be construed as me supporting the move. I now
> regret not commenting further at the time.
I didn't say that you supported that, just that you was aware and didn't
complain about it being such a bad idea.
> The problem is we now have a split between how shell function indentation is
> done in OE-Core and how it is done elsewhere, which as I'm sure you can
> understand is also a suboptimal situation.
The split was there before too, because more recipes were using some
number of spaces than recipes using tabs "correctly".
> > When this was discussed about a year ago in TSC, the most important
> > reason was complicating backports, you can read something about it my RFC:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090135
> > .html Now close to creating dylan branch for meta-openembedded is imho best
> > time to do this, not many changes from released dylan will be backported to
> > danny, because people will start moving to newer release instead of
> > backporting more and more stuff to old one (also resolving possible
> > whitespace merge conflict it not hard). Causing conflicts for merge was
> > IIRC most important reason why my proposal was rejected for oe-core.
>
> We've been through this with OE-Core. We do do a significant number of
> backports and it has been painful when whitespace has changed. The TSC
> decision was taken in order to avoid this.
Advantage with this is that if you backport patch with different whitespace,
worse you can cause is few spaces in shell task in danny recipe.
> > And TSC minutes which discussed it say:
> > Reluctant conclusion: tabs for shell, 4 spaces for python.
> >
> > So please stop trying to show it as action of one maintainer who
> > decided to go against TSC decision and to scr3w everybody.
>
> The problem with this is that you've effectively added pressure on Richard to
> change the the policy in OE-Core despite the explicit decision not to make
> this change there.
>
> This kind of overall policy change *must* be done everywhere and not just in
> one place or even the majority of places. We shouldn't ever need to be in a
> position where OE-Core says you must do one thing and meta-oe and other layers
> say you must do the opposite.
That's why I was asking to change styleguide and allow new metadata to
be submitted with spaces, as it's only aestetic so changing styleguide
wouldn't force to change every recipe (the same as many recipes having
RDEPENDS next to DEPENDS instead of near the end of file next to
do_package and FILES_ etc.).
Cheers,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
prev parent reply other threads:[~2013-05-22 15:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 19:36 OE TSC Minutes 7 May 2013 Jeff Osier-Mixon
2013-05-21 21:45 ` Martin Jansa
2013-05-22 8:31 ` Andreas Müller
2013-05-22 10:31 ` [oe] " Burton, Ross
2013-05-22 11:01 ` Andreas Müller
2013-05-22 13:41 ` Burton, Ross
[not found] ` <519CCFFF.2060506@windriver.com>
2013-05-22 14:49 ` Martin Jansa
2013-05-22 15:11 ` Paul Eggleton
2013-05-22 15:19 ` Martin Jansa [this message]
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=20130522151950.GL32431@jama \
--to=martin.jansa@gmail.com \
--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