All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: OpenEmbedded Devel List <openembedded-devel@lists.openembedded.org>
Subject: Re: Splitting meta-oe?
Date: Tue, 20 Feb 2018 23:41:15 +0000	[thread overview]
Message-ID: <1519170075.24236.345.camel@linuxfoundation.org> (raw)
In-Reply-To: <CA+chaQd=QE4fc32LDKepRsNn0gtuyQSfFi3aQ2YxmRbZtJjp1Q@mail.gmail.com>

On Tue, 2018-02-20 at 23:27 +0100, Martin Jansa wrote:
> Richard, I agree with all you said.
> 
> But I still don't see how replacing meta-oe git repository with 10
> different git repositories helps with anything.
> 
> It won't give you more time, it would only cause more work to already
> exhausted and (re)tired meta-oe maintainers.

I'm actually very worried about these (re)tired maintainers. If the
layers were more independent it would allow some of the patch handling
responsibilities and testing responsibilities to move to other people,
reducing the load on those maintainers.

Obviously this can't happen with everything all at once but I think
some pieces of the current repo may not be far away or that difficult
to separate out.

Therefore raising the question doesn't seem unreasonable.

The separate layers and maintainership is the way we designed the new
layered approach to OE to scale.

> It won't make the layers independent.

It won't, but it would give people more of a reason to fix it.

> It won't improve existing tooling.
> 
> It won't improve automated upgrades or testing.
> 
> Yes meta-oe needs to improve and it would be great to have layers as
> those fancy colorful boxes from Yocto documentation, which you can
> willy-nilly add to your BBLAYERS without any dependencies. But that's
> not how it is now and splitting the repository alone won't help with
> that. If there are people willing to make it work better, then they
> can improve it in existing git repository and when it works well and
> there are really independent layers, then we can re-evaluate
> splitting the independent ones to separate repositories for easier
> consumption.

It alone will not change things but it *might* just trigger more people
to get involved, help and take some of the workload from those
maintainers who are overloaded right now. Its a chicken and egg
problem, our difference is we disagree on which step might help. We've
tried the monolithic repo for quite a while, it might be time to try a
different approach maybe with one piece of meta-oe?

Cheers,

Richard
[away tomorrow so further replies may be delayed]


  parent reply	other threads:[~2018-02-20 23:41 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 10:45 Splitting meta-oe? Burton, Ross
2018-02-20 14:15 ` Joe MacDonald
2018-02-20 16:50 ` akuster808
2018-02-20 17:13   ` Bruce Ashfield
2018-02-20 18:52     ` Khem Raj
2018-02-21  0:51       ` Bruce Ashfield
2018-02-21  8:49         ` Martin Jansa
2018-02-21  9:06           ` Martin Jansa
2018-02-21  9:48             ` Andrea Adami
2018-02-21 10:22               ` Martin Jansa
2018-02-21 14:02                 ` Joe MacDonald
2018-02-21 14:14                   ` Burton, Ross
2018-02-21 14:58                     ` Patrick Ohly
2018-02-21 15:01                       ` Otavio Salvador
2018-02-21 19:33                       ` Andreas Oberritter
2018-02-22  9:18                         ` Patrick Ohly
2018-02-21 14:20                   ` Tom Rini
2018-02-21 14:44                     ` Joe MacDonald
2018-02-21 13:34           ` Bruce Ashfield
2018-02-21 13:38             ` Bruce Ashfield
2018-02-21 13:45           ` Joe MacDonald
2018-02-21 13:55             ` Bruce Ashfield
2018-02-21 13:59               ` Otavio Salvador
2018-02-20 17:46   ` Richard Purdie
2018-02-20 18:00     ` Tim Orling
2018-02-20 18:28       ` Martin Jansa
2018-02-20 18:40       ` Khem Raj
2018-02-20 18:52         ` Richard Purdie
2018-02-20 19:15           ` Khem Raj
2018-02-20 21:55             ` Richard Purdie
2018-02-20 22:27               ` Martin Jansa
2018-02-20 23:17                 ` Andreas Müller
2018-02-20 23:41                 ` Richard Purdie [this message]
2018-03-17  3:50                   ` Trevor Woerner
2018-03-17 14:23                     ` Philip Balister
2018-03-18  5:49                       ` Trevor Woerner
2018-02-21  0:07           ` Otavio Salvador
2018-02-21  0:10             ` Otavio Salvador
2018-02-21 13:57               ` Tom Rini
2018-02-21 14:00                 ` Otavio Salvador
2018-02-21 14:48                   ` Tom Rini
2018-02-21 14:09                 ` Martin Hundebøll
2018-02-22  6:53                   ` Jonas Bonn
2018-02-22  9:27                     ` Patrick Ohly
2018-02-22  9:40                       ` Otavio Salvador
2018-02-21 15:54           ` Patrick Ohly
2018-02-20 20:32         ` akuster808
2018-02-20 19:06     ` Khem Raj
2018-02-20 16:54 ` Vesa Jääskeläinen
2018-02-20 18:49 ` Khem Raj
2018-02-28 17:17 ` Alexander Kanavin
2018-02-28 21:33   ` Andreas Müller
2018-03-01  1:20     ` akuster808
2018-03-01  8:46     ` Alexander Kanavin
2018-03-01  1:17   ` akuster808
2018-03-01  9:04     ` Alexander Kanavin
2018-03-01 18:44       ` akuster808
2018-03-01 18:46         ` Alexander Kanavin
2018-03-01 22:11         ` Bruce Ashfield
  -- strict thread matches above, loose matches on Subject: below --
2017-02-17 17:07 Burton, Ross
2017-02-17 17:24 ` Andreas Müller
2017-02-17 18:02   ` Martin Jansa
2017-02-17 18:28     ` Joe MacDonald
2017-02-17 19:45       ` Philip Balister
2017-02-20  3:31         ` Richard Purdie
2017-02-20  4:28           ` Joe MacDonald
2017-02-20 11:18           ` Martin Jansa
2017-02-22 16:15             ` akuster808
2017-02-17 20:54       ` Andreas Müller
2017-02-18 21:35     ` Burton, Ross
2017-02-17 21:55 ` akuster808
2017-02-18  0:53 ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1519170075.24236.345.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=martin.jansa@gmail.com \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.