[Openembedded-architecture] Consistent white-space indentation in metadata layers

[Richard Purdie]

On Thu, 2017-05-04 at 13:31 +0200, Martin Jansa wrote:
> There is 179 commits in morty branch since morty was released
> (2a59d0fa7bda78927435603e3049ce373cf6a198..123962018251dfb1d6ca5aa5c0
> d02534007de3ab)
> git diff --stat shows:
>  181 files changed, 3869 insertions(+), 1104 deletions(-)
> 
> git diff --stat without modified .patch files:
>  115 files changed, 559 insertions(+), 394 deletions(-)
> 
> With only 184 tabs in unified diff (not counting modified .patch
> files)
> or 87 tabs in modified lines (with git diff -U0)
> 
> Lets see how many more changes will be merged to morty after pyro is
> released.
> Less then 1/5 of what was merged so far?
> e.g. with krogoth there was 338 changes in total since krogoth
> release and only
> 49 since morty release
> OE @ ~/openembedded-core $ git log --oneline
> 9838f8d077d16e52ad592879d65a9e8350b93075..origin/krogoth | wc -l
> 338
> OE @ ~/openembedded-core $ git log --oneline
> 0900fed3fb6eec62e9e25f6d03af934f9776d105..origin/krogoth | wc -l
> 49
> 
> Yes, it's not my decision to make, but there is no need to exaggerate
> how many conflicts will this cause for backports.

I don't think people realise how much we struggle with stable branch
maintainership. We've had zero patches being backported for over a
month now as we hit build failures Armin hasn't been able to dig into
and resolve. Its just a simple build failure, right? Nobody is
particularly interested in helping fix build failures unless I refuse
patches until they're fixed and that doesn't really work for the stable
branch.

My point is the stable maintainers are overworked, under appreciated
and anything which makes their work more painful is "not good".

I'd like to have much better 'time to market' on stable patches and we
get complaints about that but its proving tough.

> > One of the reasons I've not pushed this for as long is that I still
> > worry about the precedent that meta-oe set in doing this. A TSC
> > decision was ignored and no action was taken. If we now decided to
> > change/overrule/replace the TSC decision, it does continue a
> > dangerous
> > precedent.
> And what about the interpretation of that TSC decision I had?
> 
> That it's not worth the pain it would cause to the people
> handling the patches, but not strictly preventing anyone from doing
> it in his own layers and self-inflict the pain.
>
> I've read the minutes few times and I still don't see anything about
> forbidding any layer maintainer to do it if he doesn't mind the extra
> work (or new layers which are starting from scratch so don't have
> this backporting issue). 2 from 5 TSC members approving the change in
> meta-oe might indicate that they interpreted it the same or similarly
> and there was no dangerous precedent.

The discussion clearly says "tab for shell and 4 spaces for python" as
the reluctant consensus by one of the two members you mention above.
The discussion makes no mention of exactly which layers this applies
to. You are correct in stating it doesn't explicitly forbid a layer to
deviate, equally nothing in there allows it either.

No TSC meeting has ever "forbidden" me from doing quite some number of
things. It doesn't mean I can do them.

Basically, the implication here is the the TSC has no authority over
meta-oe and it can do whatever its maintainers like?

Stepping back I think there is a wider perspective that needs to be
considered for the project overall too. There are things that have gone
into OE-Core I didn't like and still don't like. I took them and moved
on, there has to come a point where that happens for the greater good
of the overall project. We've all probably spent far more time on this
than it deserves already.

Cheers,

Richard