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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2013-05-22 at 16:49 +0200, Martin Jansa wrote:
> 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.

What I don't want to see is a ton of changes against OE-Core changing
tabs to spaces in the shell functions. This is a particularly nasty
change which breaks patch application across the flag day and breaks the
way several people are using the project and code for exchange of
features. Whilst there may have been minimal cases in meta-oe where the
change was necessary, the situation in the core is different and there
are more changes needed there since it is pretty standardised on tabs.

I've been explicitly asked by various community members not to do what
we did with the python change again as it was invasive and it did cause
people significant pain. There is also no pressing need to change the
shell situation, there was significant technical grounds for the python
spacing change (for example we'd not even be considering python 3 if we
hadn't fixed the tabs).

I'm actually rather annoyed the TSC members agreed to one thing, then
publicly backed something else thereby undermining the TSC and the
agreement that was reached. There is little that I can do about this
other than state my opinion :(.

Rightly or wrongly, OE-Core is continuing with the style its always
promoted which is spaces in python, tabs in shell.

Cheers,

Richard