summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'glep-0003.rst')
-rw-r--r--glep-0003.rst124
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/