1 |
GLEP: 3 |
2 |
Title: Ebuild maintainter extension GLEP |
3 |
Version: $Revision: 1.1 $ |
4 |
Last-Modified: $Date: 2003/06/10 17:31:01 $ |
5 |
Author: Caleb Tennis <caleb@gentoo.org> |
6 |
Status: Deferred |
7 |
Type: Standards Track |
8 |
Content-Type: text/x-rst |
9 |
Created: 09-Jun-2003 |
10 |
Post-History: 10-Jun-2003 |
11 |
|
12 |
|
13 |
Abstract |
14 |
======== |
15 |
|
16 |
Gentoo's portage tree attempts to provide a self contained, easy to use, and |
17 |
automatic installation procedure for as many packages as can be maintained by |
18 |
developers. |
19 |
|
20 |
This GLEP proposes allowing non-core Gentoo developers to be considered as |
21 |
ebuild maintainers sponsored via a core Gentoo developer. This system will |
22 |
allow more ebuilds to be available in portage with active maintainers for |
23 |
those ebuilds. |
24 |
|
25 |
This GLEP only applies to EBUILD based bugs that contain a request for a |
26 |
package to be committed or version bumped within portage. |
27 |
|
28 |
Motivation |
29 |
========== |
30 |
|
31 |
As of the first draft of this GLEP, there are 1387 EBUILD bug requests in |
32 |
Gentoo's bugzilla database. Many of these requests contain ebuilds that |
33 |
have been submitted by the bug reporter and are simply awaiting a Gentoo |
34 |
developer to sponsor the submittal of the ebuild. |
35 |
|
36 |
|
37 |
|
38 |
Rationale |
39 |
========= |
40 |
|
41 |
Gentoo's portage tree already contains the most popular ebuilds for packages |
42 |
available today. Many teams exist that are responsible for maintaining these |
43 |
core ebuilds in the portage tree. But, for ebuilds that are not as commonly |
44 |
used, there is no good focal point upon which to rest these ebuilds. |
45 |
|
46 |
For example, any submitted ebuild that is a KDE application gets routed to the |
47 |
KDE team. However, the KDE team may be unfamiliar with the submitted ebuild. |
48 |
A new graphical MySQL editor may be submitted to the MYSQL team, but none of |
49 |
the members of that team may be familiar or have the desire to learn a new |
50 |
program to submit it to portage. |
51 |
|
52 |
We want to be able to provide for as many ebuilds in portage as feasible and |
53 |
make sure that all ebuilds have some person who is responsible for |
54 |
maintenance. |
55 |
|
56 |
|
57 |
Backwards Compatibility |
58 |
======================= |
59 |
|
60 |
No current policies exist that interfere with this document. |
61 |
|
62 |
|
63 |
Implementation |
64 |
============== |
65 |
|
66 |
Incoming ebuild bug reports should continue to be processed as normal. |
67 |
|
68 |
Bug reports that *do not* contain an attached ebuild should be marked as |
69 |
NEEDINFO. A message asking the user to create and submit an ebuild should be |
70 |
attached to the bug. |
71 |
|
72 |
Bug reports that *do* have an attached ebuild should be responded to with |
73 |
a message asking if the reporter agrees to provide maintence and support for |
74 |
the ebuild and package. |
75 |
|
76 |
If a reporter *does not* agree to provide package maintence, the bug report |
77 |
should be marked WONTFIX. |
78 |
|
79 |
If a reporter *does* agree to provide package support, the ebuild should |
80 |
be added to portage with a note in the ChangeLog that the reporter is |
81 |
considered the maintainer of that particular ebuild. |
82 |
|
83 |
Any incoming bug reports that are related to this ebuild should continue to |
84 |
get processed as normal. The team that the ebuild goes to should then CC the |
85 |
author of the ebuild. Optionally, if a docs-team member has prior knowledge |
86 |
that the ebuild is externally maintained, he/she can add that person to the CC |
87 |
list. |
88 |
|
89 |
Security |
90 |
======== |
91 |
|
92 |
**At the very least**, all ebuilds must be looked over by the developer |
93 |
handling the commit. |
94 |
|
95 |
In no case should a submitted digest file be used. The developer is |
96 |
responsible for creating the digest file based on an actual download of the |
97 |
source code. |
98 |
|
99 |
Potential breaches in security can still exist, however. The developer |
100 |
handling the installation should take every step to ensure that no ebuild, |
101 |
package, or other files have been compromised. |
102 |
|
103 |
|
104 |
Future |
105 |
====== |
106 |
|
107 |
Current proposals to rethink Gentoo portage and bug handling (a.k.a Herds) are |
108 |
still in negotiation. It is the intention of the author of this GLEP to evolve |
109 |
the concept of this GLEP as the Herds concept matures and stabilizes. |
110 |
|
111 |
|
112 |
References |
113 |
========== |
114 |
|
115 |
.. [#GLEP2] GLEP 2, Sample ReStructuredText GLEP Template, Goodyear, |
116 |
(http://glep.gentoo.org/glep-0002.html) |
117 |
|
118 |
|
119 |
Copyright |
120 |
========= |
121 |
|
122 |
This document has been placed in the public domain. |
123 |
|