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

[Martin Jansa]

On Thu, May 04, 2017 at 01:35:59PM +0100, Richard Purdie wrote:
> 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".

Count me in for master branch maintainer who feels overworked and
planing to spend his free time on something more fun and appreciated.

> 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.

And the only reasons for this consensus were that it would cause more
work for people maintaining the layer, mainly you for oe-core, right?

(9:14:04 AM) RP: and I do feel strongly about this as one of the
people who would be significantly impacted by this

And I agree with that, if you don't want to deal with this and TSC didn't
decide that it's worth it, then nothing forces you to do it or accept
such patch, but I still don't see the reasoning why new layers (or
layers with maintainers willing to deal with it) should continue to use
this inconsistent indentation when they don't have the historical
reasons to keep it.

Or were you impacted by this change in meta-oe, meta-smartphone,
meta-webos, meta-qt5, meta-lune*, meta-lg* layers? Other than these
discussions on ML?

> 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?

I don't see this implication.

If there is TSC decision that libreoffice recipes shouldn't be included
in oe-core, because they are maintenance nightmare and not used by
majority projects, would you also complain if someone merges libreoffice
recipes to e.g. meta-oe layer?

> 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.

Agreed

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: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20170504/e85619c3/attachment-0002.sig>