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.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
