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

Martin Jansa martin.jansa at gmail.com
Wed May 22 15:19:50 UTC 2013


On Wed, May 22, 2013 at 04:11:02PM +0100, Paul Eggleton wrote:
> On Wednesday 22 May 2013 16:49:25 Martin Jansa wrote:
> > 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/09016
> > 2.html Khem:
> > http://lists.openembedded.org/pipermail/openembedded-devel/2013-April/09020
> > 3.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/09018
> > 4.html
> 
> I didn't feel like I had good reason to object other than what had already 
> been discussed. That should not be construed as me supporting the move. I now 
> regret not commenting further at the time.

I didn't say that you supported that, just that you was aware and didn't
complain about it being such a bad idea.

> The problem is we now have a split between how shell function indentation is 
> done in OE-Core and how it is done elsewhere, which as I'm sure you can 
> understand is also a suboptimal situation.

The split was there before too, because more recipes were using some
number of spaces than recipes using tabs "correctly".

> > 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.
> 
> We've been through this with OE-Core. We do do a significant number of 
> backports and it has been painful when whitespace has changed. The TSC 
> decision was taken in order to avoid this.

Advantage with this is that if you backport patch with different whitespace,
worse you can cause is few spaces in shell task in danny recipe.

> > 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.
> 
> The problem with this is that you've effectively added pressure on Richard to 
> change the the policy in OE-Core despite the explicit decision not to make 
> this change there.
> 
> This kind of overall policy change *must* be done everywhere and not just in 
> one place or even the majority of places. We shouldn't ever need to be in a 
> position where OE-Core says you must do one thing and meta-oe and other layers 
> say you must do the opposite.

That's why I was asking to change styleguide and allow new metadata to
be submitted with spaces, as it's only aestetic so changing styleguide
wouldn't force to change every recipe (the same as many recipes having
RDEPENDS next to DEPENDS instead of near the end of file next to
do_package and FILES_ etc.). 

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20130522/556c5cec/attachment-0002.sig>


More information about the Openembedded-devel mailing list