On May 22, 2013, at 7:49 AM, Martin Jansa <[email protected]> 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: [email protected] > _______________________________________________ > Openembedded-devel mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-devel _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
