Re: [OE-core] OE TSC Minutes 7 May 2013

[Mark Hatle <mark.hatle@windriver.com>]

On 5/22/13 9:33 AM, Andreas Müller wrote:
> On Wed, May 22, 2013 at 4:02 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 5/22/13 3:31 AM, Andreas Müller wrote:
>>>
>>> On Tue, May 21, 2013 at 9:36 PM, Jeff Osier-Mixon <jefro@jefro.net> wrote:
>>>>
>>>> OpenEmbedded Technical Steering Committee
>>>> 7 May 2013
>>>>
>>>> Attendees:
>>>>     Koen (koen)
>>>>     Khem (khem)
>>>>     Fray (fray)
>>>>     Paul (bluelightning)
>>>>     Richard (RP)
>>>> Apologies:
>>>>
>>>> Notes: Jefro
>>>>
>>>> Agenda at a glance:
>>>>
>>>> 1. pick a chair
>>>> 2. new issues
>>>> 3. lingering issues
>>>> a. systemd merge unhappiness
>>>> 4. projects in progress - status
>>>> a. oe-classic recipe migration status
>>>> b. oe-core release
>>>> c. systemd into master
>>>> d. meta-oe appends/overlayed recipes RFC
>>>> e. 1.5 planning
>>>> 5. infrastructure
>>>> a. mailing list moving to YP server, in progress
>>>> b. oe.org flooded
>>>> 6. projects deferred
>>>> a. raise awareness of "janitor" list, QA "bugs"
>>>> b. document whitespace changes to the shell
>>>> c. raise ntp with the Yocto Project [RP]
>>>>
>>> There are three issues I would like to comment on:
>>>
>>> 1. systemd migration:
>>>
>>>   From what I see the only major step left over is to bury meta-systemd.
>>> The only appends found there are those for oe-core. I asked for this
>>> long time ago [1] and support was offered but...
>>>
>>> 2. indention:
>>> Reading between the lines there is some unhappiness on meta-oe using
>>> four spaces for shell and python code. I personally agree with Martin
>>> here because I have not seen a technical reason for shell requiring
>>> tabs so far. To me this looks like a style decision which increases
>>> the burden to submit for low-skilled people like me. Could somebody
>>> please enlighten me: For what technical reason do we need tabs in
>>> shell code?
>>
>>
>> (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.
>
> ??? - see
>
> commit 604d46c686d06d62d5a07b9c7f4fa170f99307d8
> Author: Richard Purdie <richard.purdie@linuxfoundation.org>
> Date:   Wed Jul 11 17:33:43 2012 +0000
>
>      Convert tab indentation in python functions into four-space
>
>      Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>
>
> So now at least I am totally confused ( which might be an argument
> preferring only one type of indentation )

Sorry, I've been working on too many projects lately..  I switched python and 
shell in what I was saying.

It's python that's four spaces, shell that's tabs.. but the rational is the 
same.  Python is strict, shell is not.. existing conventions were used.

Sorry for the confusion.

--Mark

>>
>> 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.
>
> Please give me the link to the decision written and I'll follow the community.
>
>> 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..)
>>
>
> Please don't misunderstand me: I thought I have read some sidenotes on
> meta-oe using four-spaces for all type of code:
>
> (9:31:13 AM) fray: ok.. so what about the comment of an 'oe'
> maintainer ignoring the TSC?
>
> Maybe I am over-interpreting this. Whatever, this is not that
> important and should stop here - we face other challenges - sorry for
> the noise
>
> Andreas
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>