public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] OE TSC Minutes 7 May 2013
Date: Wed, 22 May 2013 16:49:25 +0200	[thread overview]
Message-ID: <20130522144925.GJ32431@jama> (raw)
In-Reply-To: <519CCFFF.2060506@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 3852 bytes --]

On Wed, May 22, 2013 at 09:02:39AM -0500, Mark Hatle wrote:
> (Background) When the spacing was decided, looking at the existing OE recipes 
> and classes, the majority of things were indented such that python used tabs, 
> and recipe (shell scripting) used spaces.  During the cleanup of the scripting 
> sections it was decided that the least impact to all was desirable.  Thus the 
> python-tab, shell-spaces convention.

"python used tabs, and recipe (shell scripting) used spaces"
"python-tab, shell-spaces convention" 

... 

you have it WRONG

> It's true that shell scripts don't really care about indenting, so the four 
> spaces is just a convention that was decided on based on that.  The concern is 
> that if we go in and change the convention now, it's going to cause a lot of 
> potential disruption.
> 
> So the answer isn't that it's a technical reason, it's a community reason. 
> Don't rock the boat on something that is just going to annoy people and provide 
> no actual help.  So far I haven't seen a compelling argument to change the 
> convention BTW, other then (paraphrase) "I don't like spaces, and want to use 
> tabs".  (Note, when I write shell scripts, I prefer tabs as well..)

layers in meta-oe repo were using tabs in less shell tasks then some
amount of spaces.

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/090162.html
Khem: http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090203.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/090184.html

Joe who also maintains layer in meta-oe repo agreed that it's good idea:
http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090181.html

Otavio also contributes a lot and agreed with that change:
http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/090146.html

Andreas is sending also lot of patches and formally supported that
change now.

You on other hand don't even follow meta-networking/MAINTAINERS file
when sending patches...

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.

Original proposal here
http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026176.html
was also supported by
Chris http://lists.linuxtogo.org/pipermail/openembedded-core/2012-July/026201.html

Since the change I had to manually update only 6-10 patches submitted for
meta-oe and backporting patches from dylan to danny or denzil is not
influenced by this change.

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.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  parent reply	other threads:[~2013-05-22 14:51 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 [this message]
2013-05-22 15:11       ` Paul Eggleton
2013-05-22 15:19         ` Martin Jansa

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=20130522144925.GJ32431@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox