diff options
Diffstat (limited to 'glep-0003.rst')
-rw-r--r-- | glep-0003.rst | 124 |
1 files changed, 124 insertions, 0 deletions
diff --git a/glep-0003.rst b/glep-0003.rst new file mode 100644 index 0000000..2b2a944 --- /dev/null +++ b/glep-0003.rst @@ -0,0 +1,124 @@ +GLEP: 3 +Title: Ebuild maintainter extension GLEP +Version: $Revision$ +Last-Modified: $Date$ +Author: Caleb Tennis <caleb@gentoo.org> +Status: Deferred +Type: Standards Track +Content-Type: text/x-rst +Created: 09-Jun-2003 +Post-History: 10-Jun-2003 + + +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 +========== + +.. [#GLEP2] GLEP 2, Sample ReStructuredText GLEP Template, Goodyear, + (http://glep.gentoo.org/glep-0002.html) + + +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/ |