Gentoo accepts user contributions via a number of venues. Bugzilla,
the most traditional of them is suitable for helping developers fix
their packages but is strictly developer-oriented. Proxy maintenance
is a great way to maintain packages by non-developers but requires
significant effort from both contributors and developers. Third-party
repositories are cheap to create but not friendly to end users.
All this considered, there seems to be a gap between overlays and proxy
maintenance. GURU aims to fill this gap, by combining relatively low
effort required to push with high visibility of well-known official
repository. While using a rather different design, it is meant to be to
Gentoo what AUR is to Arch Linux.
The project is somewhat similar to Sunrise, except that it eliminates
the reliance on developers to review commits. Instead, it focuses
on Wiki-like community workflow where everybody can work together
to improve packages, and users gain reputation via doing good work.
Users who already gained reputation use it to review packages, merge
them for public consumption and at the same time raise reputation
of the users submitting them. This creates self-sustainable community
where Gentoo developer intervention is rarely necessary.
Over the history of Gentoo, I think Bugzilla can clearly be classified
as the primary venue of interaction between users and developers. Be it
bug reports, enhancement suggestions or new package requests, all
of them allowed for the users to attach patches or new ebuilds.
The most important characteristic of this venue is that the result
of user's action entirely relied on an existing Gentoo developer taking
care of it. The files attached by the users may help the developer but
the user can not directly cause anything to happen. If user submits
a new package, he can't make it happen without finding an interested
developer.
Bugzilla is presented as a canonical example of this contribution model.
The same model is expressed e.g. by e-mail submissions, IRC pastes, etc.
The Sunrise project was a historical Gentoo project built around
user-maintained, developer-reviewed package repository. At the time
when I joined Gentoo, it was the primary venue for users to work on new
packages and receive training necessary to become Gentoo developers.
After all, many new Gentoo developers at the time (myself included)
started with Sunrise.
The Sunrise model was based on a repository with two branches: a main
branch where all users worked and a reviewed branch that was meant for
public consumption. All users were expected to request review on IRC
for their changes, and only commit once receiving an approval from
a Sunrise developer. Furthermore, Sunrise developers periodically did
review late commits (again) and merge them to the reviewed branch.
Sunrise eventually become defunct due to loss of interest both
on developer and user side. Eventually, it has been discontinued
in June 2016.
The downfall of Sunrise was paralleled by rise of proxy-maintenance.
In this model, users are allowed to maintain packages straight
in the Gentoo repository, with one or more developers proxying
the commits for them.
While this concept has been (and still is) applied to individual
user-developer pairs, forming the Proxy Maintainers project was
a turning point for its growth. This project focused on gathering
developers that were interested in serving users as proxies,
and eventually replaced the 1:1 model with M:N where a number of
developers freely proxy a number of users.
The historical purpose of proxy-maint project was to find new
maintainers for abandoned packages in Gentoo. Today (and especially
since GitHub was adopted) the majority of submissions involves new
packages.
The main advantage of proxy-maint is that it allows the users to take
responsibility and share their work to all Gentoo users through
the official repository. However, applying those contributions requires
significant effort both from users and developers, and so far
the proxy-maint team is continuously overwhelmed and unable to process
contributions in satisfactory time.
Finally, another possibility for users to publish their work is to
create their own repositories, historically called ‘overlays’. There
is a great multitude of kinds of repositories and their uses. We have
personal, project and quasi-public overlays. We have repositories
focused on a single package suite, software category, and holding all
different kinds of applications. We have cross-repository dependencies,
we have overrides for Gentoo packages. We have repositories of great
quality, and literal ‘dumps’ of random ebuilds. Finally, we have
completely unpredictable mixes of all that.
The most important advantage of third party repositories is that they
are trivial to create and cheap to maintain. You can practically commit
anything you like to your personal overlay, without having to pass any
review or convince any Gentoo developer to accept it. With a little
more effort, you can get it published on the official list, and make
it possible for users to trivially start using it.
However, this implies all disadvantages of the generic case of this
model. Users are subject to a great number of repositories of varying
quality and size. If you need to find a particular package, you may be
required to choose from a number of overlays with no clear indication
which may serve your purpose better. If you add a particular overlay,
you may discover it actually overrides other packages you did not want
replaced. Finally, since there's no real supervision of what happens
in all those repositories, it is trivial to inject malware.
I believe it is worthwhile to isolate a special case of third-party
repositories — project overlays. Besides aforementioned Sunrise
project, some examples of long-lived Gentoo project overlays are
the GNOME, KDE, Science or Java overlays.
Their distinguishing quality is that they are focused on a specific yet
broad topic and supervised by actual Gentoo developers. However, they
frequently give commit access to various external contributors,
providing them with an opportunity to work with the project members (or
even become them — if you disregard the limitation of Gentoo Wiki
preventing non-developer project members).
Furthermore, those project overlays frequently serve as staging ground
for Gentoo repository ebuilds. Therefore, the work of users eventually
makes it to the official repository.
The above chart attempts to describe where GURU fits graphically.
The vertical axis represents the effort, i.e. how much time and work
adding a package takes. The horizontal axis represents user reach,
i.e. how many users will find the package added.
The middle line representing Bugzilla is taken as a reference point.
In case of Bugzilla, the actual reach depends on whether any developer
actually takes the patch/ebuild.
On one end of the graph, we have user repositories where
the effort is relatively low and user reach depends on the popularity
of particular repository. On the other end, we have commits made
directly to the Gentoo repository which have the highest reach.
Proxy-maint is placed above Gentoo as reviewing and training
contributors requires more effort (and of more people) than committing
packages yourself. Sunrise is nearby, with its high standards still
requiring significant effort and good popularity.
GURU aims to achieve similar level of popularity as Sunrise; however
with lower cumulative effort. On one hand, some users will take
the extra effort to review packages. On the other, it also provides for
one-time package submitters.
