Re: [gentoo-project] Making Gentoo more fun

[Rich Freeman]

On Sat, Feb 17, 2018 at 11:39 AM, Alec Warner <antarus@g.o> wrote:
>
> I like the idea (having myself thought about a 'core' set of packages with
> overlays) so I'm excited to see your implementation. I would avoid any
> senior / junior designations (I think it blunts your message). Senior people
> can cause screwups and break the tree and not care 'enough', just as junior
> developers can. I think this is more a difference in goals for the project
> than any specific 'experience level'.
>

++ - such relationships tend to naturally form (and might be fostered
by more active smaller teams), but they probably don't need to be
formalized as such.

I've also wondered if a more overlay-driven process might be
beneficial, and certainly others like hasufel have been proponents of
this mode.  I can think of some pros and cons:

Pros

Smaller overlays actually fit well into the metadistro model, and you
can actually have a much more blurred progression in terms of level of
QA/etc.  You can also have "competing" overlays for some parts of the
trees (which might actually be maintained by the same team), such as a
bleeding-edge kde vs stable kde overlay.  (These sorts of models
already exist but have to be shoehorned into some degree today.)

Smaller overlays may make it easier to lower the barrier to entry,
because you don't need the same level of trust.  Somebody could have
access to a chromium overlay and be closely supervised by the chromium
team and nobody else really needs to worry about them.

As Daniel mentioned eclass changes are less impactful, because each
overlay can have its private copy, which can be upgraded
independently.

Repo storage and sync overhead is reduced since not everybody will
sync every overlay.


Cons

Cross-overlay dependencies need a solution.  It could be convention
(all systems must have the base overlay, and this is the only one
allowed to have cross-repo dependencies), or there needs to be a way
to define these dependencies so that portage knows when to pull in
another repo (and which one if more than one could satisfy the
dependency).

Any kind of cross-overlay dependency loses the benefit of atomic git
commits.  It will be like working with Google's repo tool where unless
you have matching tags in every overlay it will be very difficult to
ever reproduce the same configuration.  Likewise you lose the
potential to apply CI/tinderboxing across the entire universe of
dependencies.

All those forked eclasses provide all the compatibility benefits, and
security/regression issues, of bundled libraries.

Some efforts tend to require a lot of misc cross-package work.  For
example, the systemd team has done a lot of work to maintain units for
various packages, and while this is done in cooperation with
maintainers most of the commits are done directly by the systemd team
and might not get done at all otherwise.  For this to happen in an
overlay-centric world a team like systemd would need commit rights
everywhere, or would need to rely on pull requests getting merged by
these teams, or worst case they'd end up having to maintain forks of
overlays just to add units, which of course seems wasteful.


You also still deal with the community issues.  From a QA standpoint
having people in their own sandboxes may ease things.  On the other
hand, if members of the community have interpersonal conflict on
lists/irc/etc then we still need to deal with that, and then we might
be asking some overlay with three committers to kick one of them out
because they don't get along with somebody who isn't involved with
that overlay, or we have to live with perpetual conflict under the
Gentoo banner that we're incapable of dealing with.  Of course, the
same issue exists even though we are in the same repo, since smaller
teams feel the same impact, but splitting things up might lead to more
of a sense of ownership by these teams, which can be both good and
bad.

I guess QA standards are also a challenge.  Are QA standards still
imposed from above (thou shalt do these things to be part of the
distro)?  Or are they more like certification standards (thou shalt do
these things to have the stable label applied to your overlay)?  Will
this also result in forks?  For example, suppose the chromium project
has no interest in a stable overlay, but there is still demand for
one, and the two groups can't get along.  Would the stable camp need
to basically fork the chromium overlay just to create a
chromium-stable?  Is this a better use of resources?

If it sounds like I'm negative on the whole thing it is more because I
think it is promising but keep thinking of issues that would need to
be overcome.  Also, every time I ever touch a project that uses
Google's repo tool I inevitably end up cursing it at some point.  That
isn't necessarily a reason not to try, but we do need to think such
things out.  To some degree Funtoo has the luxury that it gets to
start with a repo where all the benefits of a single tree already
exist, so the cons might not be as apparent there.

-- 
Rich