en/glep/glep-0017.txt

GLEP: 17
Title: Resolution for Aging EBuilds
Version: $Revision: 1.1 $
Last-Modified: $Date: 2003/11/24 14:20:23 $
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 artifically 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 acceptal 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 vein.


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 document has been placed in the public domain.
1	GLEP: 17
2	Title: Resolution for Aging EBuilds
3	Version: $Revision: 1.1 $
4	Last-Modified: $Date: 2003/11/24 14:20:23 $
5	Author: Caleb Tennis <caleb@gentoo.org>
6	Status: deferred
7	Type: Standards Track
8	Content-Type: text/x-rst
9	Created: 21-Nov-2003
10	Post-History: 24-Nov-2003
11
12
13	Abstract
14	========
15
16	Many of the ebuild scripts found within Gentoo's Portage have come as a direct
17	result of user submission via Gentoo's Bugzilla interface. However, a large number
18	of open ebuild requests remain in Bugzilla. This GLEP attempts to resolve these
19	requests.
20
21	Status
22	======
23
24	Timed out
25
26
27	Motivation
28	==========
29
30	As of the first draft of this GLEP, there are 1517 EBUILD bug requests in
31	Gentoo's bugzilla database. These requests generally fall into three categories:
32
33	1. The package is important to Gentoo users, but has simply has not yet made
34	its way into Portage.
35
36	2. The package is mostly unimportant to Gentoo users
37
38	3. No ebuild has been provided with the bug request.
39
40	Leaving these requests open does not help Gentoo. Not only does the bug count
41	become artifically inflated, but bug maintenance also becomes more difficult adding
42	to open requests that developers must sift through.
43
44	Furthermore, having a policy in place as to how ebuild bug requests are handled is
45	important for consistency and accountability.
46
47	Rationale
48	=========
49
50	Portage simply cannot contain an automated ebuild for every software package available.
51	Ebuilds that are included are done so mostly based on the whim and knowledge of
52	developers. Many software packages are of interest only to a small subset of end users,
53	and as such would be a misuse of resources by including in Portage.
54
55
56	Implementation
57	==============
58
59	This implementation applies only to requests which have been idle in the database
60	for an extended period of time. The recommended time is 90 days.
61
62	After this period, the bugs should be handled in the follow manner:
63
64	* The bug should be closed as a WONTFIX
65	* The following note should be included in the description:
66	``No developer has sponsored the ebuild within 90 days of request.
67	Closing per GLEP policy #xx``
68
69
70	Repercussions
71	=============
72
73	The (systematic) denial of the inclusion of ebuilds into the Portage tree may leave
74	some users to feel slighted because their ebuild was not accepted into Portage.
75	This is an unfortunate side effect of a system that relies on acceptal or denial.
76
77
78	Future
79	======
80
81	It may be desirable to provide an official repository for abandoned ebuilds to go.
82	Any attachments to these bug reports could be placed here, so that the author's effort
83	has not gone in vein.
84
85
86	Backwards Compatibility
87	=======================
88
89	No current policies exist that interfere with this document.
90
91
92	References
93	==========
94
95	.. [#GLEP2] GLEP 2, Sample ReStructuredText GLEP Template, Goodyear,
96	(http://glep.gentoo.org/glep-0002.html)
97
98
99	Copyright
100	=========
101
102	This document has been placed in the public domain.