User:MGorny/GLEP:MMD

GLEP : Gentoo as a meta-metadistribution
Type	Informational
Status	Draft
Author	Michał Górny <mgorny@gentoo.org>
Editor
Replaces
Replaced by	(none)
Requires
Post History

Motivation

One of the most apparent facts about Gentoo these days is that it is seriously undermanned. Only in the eight months of 2017 so far 47 Gentoo developers have been retired. During the same period, only 4 developers have joined.

According to a recent survey of Gentoo projects, around 26% of the projects at the time were completely dead. 12% more were in urgent need of additional volunteers. The first group totals to the maintainers of around 1300 packages. Combined with around 1500 maintainer-needed packages, this indicates that almost 15% of total packages in Gentoo are unmaintained. And this is just a tip of the iceberg since there is certainly also a large number of packages that have apparent maintainers but are not really maintained.

There are currently 166 Gentoo developers with commit access. A number of them have little to no time for Gentoo, requiring others to do more work. Some developers have to participate in over 15 different projects just to prevent everything from falling apart. Usually a single developer effectively maintains 1000-2000 packages, with the most active developers having even around 2500.

And this only concerns pure ebuild work. In the end, some developers are overburdened to their limits and yet they are not capable of making Gentoo stop falling behind. This results in increasing frustration, and in the end more retiring developers. Which in turn means that the remaining developers become overburdened even more.

With this sad state of affairs, the quality of Gentoo as a distribution is rapidly decreasing. With reducing usefulness, Gentoo attracts less users and even less developer candidates. This requires urgent action, and drastic changes.

To be honest, Gentoo has never been very successful as a distribution. Its strength laid in being a meta-distribution — a great building block for other projects. Pentoo, Sabayon, SystemRescueCD are just a few examples of those. The best way forward for Gentoo is to reduce focus on the unsuccessful areas, and focus on those where it is strong.

Furthermore, Gentoo has a number of long-time active contributors who do not find the current, package-based contribution model appealing. They are sidetracked by many Gentoo developers, resulting in a net loss to the distribution. Finding appropriate contribution model would certainly gain Gentoo many new contributors.

Let's take the most successful Gentoo metadistribution model even further — make it a meta-metadistribution.

Specification

A meta-metadistribution

The purpose of a meta-metadistribution is to provide even more basic distribution building blocks than Gentoo used to as a metadistribution. A meta-metadistribution focuses on providing good distribution building ideas and standards. All of them are well-reviewed and discussed by our developers, and include comments that could help other distributions choose how to adapt them. Reference implementations are strongly discouraged as they bias our clients towards a specific implementation.

Ideamaking workflow

The current Gentoo workflow of isolated policy making and GLEPs are not sufficient to sustain a meta-metadistribution. They are replaced by a new ideamaking workflow that focuses on providing good feedback for every idea.

The key points are:

1. If a developer or a user has any potentially good idea, he should take it immediately to a mailing list for discussion.
2. Even if the idea turns out bad, it might provide an incentive for others to create their own ideas. Therefore, it is even beneficial to submit bad ideas.
3. Everyone is encouraged to reply to the idea with comments. All feedback is important to properly determine the implications of every idea.
4. Furthermore, people are encouraged to be inspired by existing ideas and fork the threads creating their own derivative ideas.

Providing reference implementations and summaries is discouraged to avoid biasing. Instead, our clients should read the original discussion threads to get the widest feedback.

Projects

Most of Gentoo projects become no longer useful and are disbanded. Developers and users are encouraged to discuss everything publicly, and avoid internal discussions which can result in earlier bias and loss of individual ideas.

The only projects that remain are the projects needed to technically maintain the new Gentoo: the Infrastructure team, Recruiters, Community Relations. The teams recruit new members themselves as need arises, possibly including non-developer members.

Recruiting

Everyone is equal in the new Gentoo, whether developer or not. The developer status becomes purely honorary. The recruiters give developer status to users who actively contribute to the ideamaking of Gentoo, and they maintain it as long as they keep active on the mailing lists. Developers are retired once they become no longer active.

Infrastructure

The Infrastructure team is responsible for maintaining the technical resources for the new Gentoo. Most of the current Infrastructure can be dismantled as no longer necessary — git hosting, mirrors, etc. The most important resources become the mailing list servers and the respective archives.

To avoid biasing our users towards a particular implementation of Gentoo, and to avoid wasting their time on maintaining packages, Gentoo infrastructure should use another system. Preferably Windows, to avoid biasing our users towards a particular design of Linux or any other *nix system.

Community Relations

The Community Relations team is preserved in order to watch order on the mailing lists. Their purpose is to prevent inappropriate behavior in the mailing lists. Most notably, they are expected to make sure that everybody can freely express his opinion, and that nobody tries to silence anyone else.

Copyright

This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/.