|
Line 0
Link Here
|
|
|
1 |
Package Maintainers |
| 2 |
=================== |
| 3 |
|
| 4 |
.. index:: maintainer; adding |
| 5 |
|
| 6 |
Adding new maintainers |
| 7 |
---------------------- |
| 8 |
:Source: QA |
| 9 |
:Reported: no |
| 10 |
|
| 11 |
Developers must not add other developers as package maintainers, unless |
| 12 |
the developers in question consent to that. Developers must not add |
| 13 |
projects that they are not members of as package maintainers, unless |
| 14 |
one of the project members explicitly agrees to that or the project |
| 15 |
policy explicitly permits it. |
| 16 |
|
| 17 |
*Rationale*: this policy aims to prevent package maintainers being added |
| 18 |
as backup maintainers without their consent or knowledge. What's worse, |
| 19 |
once the original maintainer resigns the packages frequently drop |
| 20 |
to backup maintainers who are neither interested in maintaining them, |
| 21 |
nor often aware why they are listed as maintainers. |
| 22 |
|
| 23 |
For example, developers used to frequently add Python team as a backup |
| 24 |
maintainer to various packages not fitting the project's profile. This |
| 25 |
includes various end-user programs written in Python. Many of those |
| 26 |
packages ended up being maintained solely by Python, and distinguishing |
| 27 |
them from packages actually within project's profile was hard. |
| 28 |
|
| 29 |
|
| 30 |
.. index:: maintainer; new packages without |
| 31 |
|
| 32 |
New packages without a maintainer |
| 33 |
--------------------------------- |
| 34 |
:Source: QA |
| 35 |
:Reported: no |
| 36 |
|
| 37 |
It is explicitly forbidden to add new packages without a dedicated |
| 38 |
maintainer. This does not apply if the package in question is not |
| 39 |
technically a new one but merely split out of unmaintained package. |
| 40 |
|
| 41 |
*Rationale*: Gentoo is currently suffering from a very large number |
| 42 |
of packages without a maintainer. There is a small group of developers |
| 43 |
trying to fix them as necessary. It is unfair and inappropriate |
| 44 |
to increase their maintenance burden by adding new packages and refusing |
| 45 |
to take care of them. |
| 46 |
|
| 47 |
|
| 48 |
.. index:: maintainer; removing |
| 49 |
.. index:: up for grabs |
| 50 |
|
| 51 |
Removing package maintainers |
| 52 |
---------------------------- |
| 53 |
:Source: QA |
| 54 |
:Reported: no |
| 55 |
|
| 56 |
When removing maintainers from a package, the developer must reassign |
| 57 |
all bugs filed for it. Furthermore, when removing the last maintainer |
| 58 |
for a package, the developer must add the following comment |
| 59 |
to ``metadata.xml``:: |
| 60 |
|
| 61 |
<!-- maintainer-needed --> |
| 62 |
|
| 63 |
Furthermore, the developer must send an 'up for grabs' mail |
| 64 |
to gentoo-dev mailing list, containing the list of packages with |
| 65 |
no maintainer. If possible, please include any information that could |
| 66 |
be helpful to future maintainers. |
| 67 |
|
| 68 |
*Rationale*: reassigning bugs is necessary to make sure that old bugs |
| 69 |
are not lost assigned to developers who are no longer interested |
| 70 |
in them. The maintainer-needed comment is meant to make it possible |
| 71 |
to easily grep for unmaintained packages. The 'up for grabs' mails aim |
| 72 |
to increase the chances of packages finding a new maintainers (compared |
| 73 |
to them silently becoming maintainer-needed). |
