en/glep/glep-0003.txt

GLEP: 3
Title: Ebuild maintainter extension GLEP
Version: $Revision: 1.1 $
Last-Modified: $Date: 2003/06/10 17:31:01 $
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 submittal 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 maintence and support for
the ebuild and package.

If a reporter *does not* agree to provide package maintence, 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 document has been placed in the public domain.

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