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

[konsolebox]

On Wed, Jun 8, 2016 at 9:16 PM, Alexander Berntsen <bernalex@g.o> wrote:
> It would be wise of us to create a novel way of involving users from
> the ashes of Sunrise.
>
> Here is my suggestion: It would be fruitful to encourage every single
> Gentoo user to have their own repository. And this repository should
> be publicly available.
>
> This way we can merge useful things from people, and they can submit
> pull-requests if they have useful things that are not in the tree.
> Before merging anything to the main tree, ebuilds should of course be
> carefully reviewed. Users could also review each other's ebuilds to
> ensure better quality ebuilds.
>
> This could lead to a future where the Gentoo tree is largely
> superseded. Every user would just have their own repository, where
> they could pick and choose packages from other users. The Gentoo tree
> would just focus on a high-quality repository of the basic/core things
> that everybody needs. Gentoo devs would spend most of their time
> maintaining curated small and useful repositories.
>
>
> While there is some work to be done to facilitate my suggestion, it
> should be a lot less work than Sunrise was. What we need short-term is
> simply documentation where we encourage users to have their own
> repositories that are available online. Next up would be setting
> Portage up to expect a user repository from the get go. The initial
> personal tree could be fork of the Gentoo tree with a remote 'gentoo'
> that they can pull from (emerge could do this automatically). This
> way, users who do not care at all, can just use Gentoo like they do
> today.
>
> The final step is the most difficult (but then again we might never
> get so far). It is two-fold. First we make the core/base repository.
> Then we identify important subsets that can be logically separated
> into repositories, and do this.
>
> Parallel to all this, we should work on tooling. It is unreasonable to
> expect people to be git experts to be effective. The workflows for
> managing user repositories doesn't need the full power of git anyway.
> It would also be good to offer hosting insofar as possible to a set of
> curated repositories we consider to be of high quality.
>
>
> In the end, Gentoo might make a gigantic leap into the future with a
> truly modular distribution. If anyone wants to look at distros that
> get this more right than Gentoo, have a look at e.g. NixOS and Exherbo.
>
> What are your thoughts?

Here's mine:

Make the layman system more open (or have a version of layman that has
more scope e.g. open-layman), but add tags to differentiate stable,
official, or trusted overlays to those which aren't: outdated,
under-provision, etc.  We have to have an open web-based registration
system where users can easily sign-up for their own overlay name which
would be mapped to a supported repository service, like Github.  The
system would time and time check for each repository for activity, and
check for updates.  It would then update the database for packages
which are provided by the overlay.  Note that it doesn't have to
always do repoman-like checks (or maybe it doesn't really have to),
but it could just do it when a user asks for a request, which could be
enqueued, and done only once in every update.

With an open system, users would be encouraged to contribute since
even if their works would not be accepted to be merged into the
official repo, it would still be available to the public for anyone to
use - where people could also easily find it.

Everything about security should already be obvious.  You can warn
users, mask user overlays by default, etc.  If we want, we can have a
comment and upvote system for every package in every overlay where
each is only dynamically created in the database if an upvote,
downvote, or comment is made.

If we are also concerned about overlay names that should only be used
officially, we should warn users that if possible, they should only
use unique names, and avoid common names, and tell them that we could
take their names for official use if we want to, granting their name
is arguably not unique.

Transfer of a package to an official repository:

If an official dev chooses to pull a package from a user overlay,
automatically it should mean that he or another dev would take place
in maintaining that package.  This would prevent the issue of
unmaintained packages, and dependencies among user overlays.

Now some people might question this since it might just drive people
to become normal contributors, and not official, but I think it's more
helpful to the system than not, since it adds more activity, and a lot
of users don't intend to become an official dev anyway.  Besides,
people can still become an official dev on later time if they would
want to, or they can be persuaded to become one.

---
konsolebox