[oe] [OE-core] OE TSC Minutes 7 May 2013

[Martin Jansa]

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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20130522/a6fbbd0c/attachment-0002.sig>