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

Khem Raj raj.khem at gmail.com
Wed May 22 20:39:44 UTC 2013


On May 22, 2013, at 7:49 AM, Martin Jansa <martin.jansa at gmail.com> wrote:

> 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

I was of a different opinion since we did not have any coding style using two was an improvement. However
since then I have been dealing with OE  newbies and using two different indentation style has compounded
the issues for them, its not one but each one of the new folks who I interact with are trying to learn writing OE
metadata. I for one happen to be familiar with metadata a bit more than them so for me having two sets was
less of an issue however I did realize the pain it was causing for on boarding new folks so I thought it would
be a better option for us to have uniform style guides for metadata.  Question about back porting the fixes is
a concern but I think who will do back porting understand OE metadata better than newbies and can deal with
it a bit better than the newbies would deal learning a new project.

> 
> 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
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel




More information about the Openembedded-devel mailing list