summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichał Górny <mgorny@gentoo.org>2017-09-14 23:14:39 +0200
committerUlrich Müller <ulm@gentoo.org>2017-10-09 12:08:51 +0200
commitc6fe2071a2e83be2203196ad7f9459941821a034 (patch)
treed81e1d9898c05917e05203af9803b581dff0d915 /glep-0017.rst
parentglep-0045: Mark Final since GLEP 1 now uses ISO 8601 dates (diff)
downloadglep-c6fe2071a2e83be2203196ad7f9459941821a034.tar.gz
glep-c6fe2071a2e83be2203196ad7f9459941821a034.tar.bz2
glep-c6fe2071a2e83be2203196ad7f9459941821a034.zip
Rename all GLEPs to .rst
Diffstat (limited to 'glep-0017.rst')
-rw-r--r--glep-0017.rst104
1 files changed, 104 insertions, 0 deletions
diff --git a/glep-0017.rst b/glep-0017.rst
new file mode 100644
index 0000000..b4fbf03
--- /dev/null
+++ b/glep-0017.rst
@@ -0,0 +1,104 @@
+GLEP: 17
+Title: Resolution for Aging EBuilds
+Version: $Revision$
+Last-Modified: $Date$
+Author: Caleb Tennis <caleb@gentoo.org>
+Status: deferred
+Type: Standards Track
+Content-Type: text/x-rst
+Created: 21-Nov-2003
+Post-History: 24-Nov-2003
+
+
+Abstract
+========
+
+Many of the ebuild scripts found within Gentoo's Portage have come as a direct
+result of user submission via Gentoo's Bugzilla interface. However, a large number
+of open ebuild requests remain in Bugzilla. This GLEP attempts to resolve these
+requests.
+
+Status
+======
+
+Timed out
+
+
+Motivation
+==========
+
+As of the first draft of this GLEP, there are 1517 EBUILD bug requests in
+Gentoo's bugzilla database. These requests generally fall into three categories:
+
+1. The package is important to Gentoo users, but has simply has not yet made
+its way into Portage.
+
+2. The package is mostly unimportant to Gentoo users
+
+3. No ebuild has been provided with the bug request.
+
+Leaving these requests open does not help Gentoo. Not only does the bug count
+become artificially inflated, but bug maintenance also becomes more difficult adding
+to open requests that developers must sift through.
+
+Furthermore, having a policy in place as to how ebuild bug requests are handled is
+important for consistency and accountability.
+
+Rationale
+=========
+
+Portage simply cannot contain an automated ebuild for every software package available.
+Ebuilds that are included are done so mostly based on the whim and knowledge of
+developers. Many software packages are of interest only to a small subset of end users,
+and as such would be a misuse of resources by including in Portage.
+
+
+Implementation
+==============
+
+This implementation applies only to requests which have been idle in the database
+for an extended period of time. The recommended time is *90* days.
+
+After this period, the bugs should be handled in the follow manner:
+
+* The bug should be closed as a WONTFIX
+* The following note should be included in the description:
+ ``No developer has sponsored the ebuild within 90 days of request.
+ Closing per GLEP policy #xx``
+
+
+Repercussions
+=============
+
+The (systematic) denial of the inclusion of ebuilds into the Portage tree may leave
+some users to feel slighted because their ebuild was not accepted into Portage.
+This is an unfortunate side effect of a system that relies on acceptance or denial.
+
+
+Future
+======
+
+It may be desirable to provide an official repository for abandoned ebuilds to go.
+Any attachments to these bug reports could be placed here, so that the author's effort
+has not gone in vain.
+
+
+Backwards Compatibility
+=======================
+
+No current policies exist that interfere with this document.
+
+
+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/.