Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Rich Freeman]

On Tue, Jun 14, 2016 at 6:30 PM, Ciaran McCreesh
<ciaran.mccreesh@××××××××××.com> wrote:
> On Wed, 15 Jun 2016 00:21:45 +0200
> "Andreas K. Huettel" <dilfridge@g.o> wrote:
>> Am Montag, 13. Juni 2016, 09:50:15 schrieb Alexander Berntsen:
>> > > I still think you're underestimating the need for centralization.
>> > > What you call a "core/base" package is probably going to end up
>> > > being anything listed in a dependency.  That is a LOT of packages,
>> > > actually - we're not just talking about libc and zlib.
>> >
>> > It's not a lot compared to how many we have today.
>>
>> Please do me a favor and emerge @system on a fresh stage
>> installation, with USE=kde ...
>>
>> ... So,
>>
>> * does KDE go into the curated repos? or
>> * will the useflag functionality be discontinued?
>
> * Your package mangler tells you you need some packages which can
> be found in the ::kde repository if you have that flag enabled, and
> suggests you either install repository/kde or disable that USE flag so
> that it can continue.
>

Ciaran can certainly correct me if I've missed anything, but the
concept here is that the curated packages are distributed across many
repositories.  So, kde would have a repository.  It would still follow
QA/etc and have controlled access, so it wouldn't be like a typical
overlay in the Gentoo sense.

What Gentoo would currently put in a project/herd/etc would go into
its own repository under this kind of model.

So, comparing some of the features of this model vs what we do today:
1.  Developers wouldn't have access to all the ebuilds in the curated
repositories.  They would only have access to the ones they contribute
to.
1a.  You could accept a contributor into a small project and not have
to give them access to the toolchain/etc.  Of course, they're still
messing with curated packages so you don't want just anybody in there.
2.  Exherbo at least requires peer review for all commits I believe.
So, even if you're committing to your "own" overlay you're still going
to need review if your overlay is a curated one.
3.  Just as with Gentoo if something is curated you can generally
count on it to follow QA, and if it is in a non-official overlay then
it is anything go and it is probably not to rely too heavily on things
like sane version numbering, deps that don't just disappear, etc.
4.  If somebody really does need to make a "tree-wide" change they're
going to need access to a bazillion repos or they'll need to ask
everybody else to commit it for them.
4a.  Conversely, people who probably shouldn't be making "tree-wide"
changes won't.
5.  To the extent that repos contain closely-related packages you can
probably make much more effective use of git branching and so on.  You
would still be limited by any dependency relationships outside the
repo.

I think the key message here is that a distributed model isn't some
kind of panacea.  It doesn't mean that any random stranger can just
open up a repo and start contributing packages that others can build
on.  Sure, they can create a repo just as somebody can create an
overlay, but users will not be able to safely rely on these packages
and if you build all kinds of dependency relationships this way you're
building on quicksand.

Likewise, many of the benefits of having a peer-review system can be
had whether or not the repository is distributed.  Those are really
orthogonal attributes.

I think there are a lot of benefits from an Exherbo-like approach, but
I think early in this thread there was a sense that this would just
open up the bazaar and all these contributors would come out of the
woodwork.

Now, what it can give you is distributed governance.  Maybe the KDE
team achieves good Gentoo QA.  We don't know how they do it.  They
don't do it the way everybody else does it.  But, somehow they get the
job done.  So, why not let the KDE team manage their own contributors
who can operate in their sandbox without having to go through some
Gentoo-wide developer process?  I don't think this is what Exherbo
actually is doing, but it theoretically is possible.  However, it
would depend on a KDE team that does in fact maintain good QA.  The
downside to distributing governance is that you may get inconsistent
quality.  Again, I don't think this is the Exherbo model.

So, a distributed model is different, and has some pros and cons.  It
isn't a panacea.

--
Rich

-- 
Rich