GLEP 3: Ebuild maintainter extension GLEP

Abstract

Gentoo's portage tree attempts to provide a self contained, easy to use, and automatic installation procedure for as many packages as can be maintained by developers.

This GLEP proposes allowing non-core Gentoo developers to be considered as ebuild maintainers sponsored via a core Gentoo developer. This system will allow more ebuilds to be available in portage with active maintainers for those ebuilds.

This GLEP only applies to EBUILD based bugs that contain a request for a package to be committed or version bumped within portage.

Motivation

As of the first draft of this GLEP, there are 1387 EBUILD bug requests in Gentoo's bugzilla database. Many of these requests contain ebuilds that have been submitted by the bug reporter and are simply awaiting a Gentoo developer to sponsor the submission of the ebuild.

Rationale

Gentoo's portage tree already contains the most popular ebuilds for packages available today. Many teams exist that are responsible for maintaining these core ebuilds in the portage tree. But, for ebuilds that are not as commonly used, there is no good focal point upon which to rest these ebuilds.

For example, any submitted ebuild that is a KDE application gets routed to the KDE team. However, the KDE team may be unfamiliar with the submitted ebuild. A new graphical MySQL editor may be submitted to the MYSQL team, but none of the members of that team may be familiar or have the desire to learn a new program to submit it to portage.

We want to be able to provide for as many ebuilds in portage as feasible and make sure that all ebuilds have some person who is responsible for maintenance.

Backwards Compatibility

No current policies exist that interfere with this document.

Implementation

Incoming ebuild bug reports should continue to be processed as normal.

Bug reports that do not contain an attached ebuild should be marked as NEEDINFO. A message asking the user to create and submit an ebuild should be attached to the bug.

Bug reports that do have an attached ebuild should be responded to with a message asking if the reporter agrees to provide maintenance and support for the ebuild and package.

If a reporter does not agree to provide package maintenance, the bug report should be marked WONTFIX.

If a reporter does agree to provide package support, the ebuild should be added to portage with a note in the ChangeLog that the reporter is considered the maintainer of that particular ebuild.

Any incoming bug reports that are related to this ebuild should continue to get processed as normal. The team that the ebuild goes to should then CC the author of the ebuild. Optionally, if a docs-team member has prior knowledge that the ebuild is externally maintained, he/she can add that person to the CC list.

Security

At the very least, all ebuilds must be looked over by the developer handling the commit.

In no case should a submitted digest file be used. The developer is responsible for creating the digest file based on an actual download of the source code.

Potential breaches in security can still exist, however. The developer handling the installation should take every step to ensure that no ebuild, package, or other files have been compromised.

Future

Current proposals to rethink Gentoo portage and bug handling (a.k.a Herds) are still in negotiation. It is the intention of the author of this GLEP to evolve the concept of this GLEP as the Herds concept matures and stabilizes.

References

Copyright

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