| 1 |
> On Tue, 9 Sep 2014 21:45:49 +0200 |
| 2 |
> Michał Górny <mgorny@g.o> wrote: |
| 3 |
>> |
| 4 |
>> Let's keep it short: I think herds don't serve any special purpose |
| 5 |
>> nowadays. Their existence is mostly resulting in lack of consistency |
| 6 |
>> and inconveniences. |
| 7 |
>> |
| 8 |
|
| 9 |
Resurrecting this thread per the last council decision: |
| 10 |
|
| 11 |
"The council is in favor of retiring herds, allowing non-maintainer |
| 12 |
aliases to exist, and having a way to distinguish between individuals, |
| 13 |
projects, and non-maintainer aliases in metadata.xml. The details of |
| 14 |
how to implement this will be worked out in the lists before the next |
| 15 |
meeting." |
| 16 |
|
| 17 |
Whether this gets worked out before the next meeting remains to be |
| 18 |
seen. However, the council is certainly interested in proposals and |
| 19 |
discussion. |
| 20 |
|
| 21 |
So, herds are going to go away. That leaves maintainers (who can be |
| 22 |
projects), and aliases (who are NOT maintainers, but can be listed in |
| 23 |
addition to maintainers). |
| 24 |
|
| 25 |
My proposal: |
| 26 |
|
| 27 |
|
| 28 |
For the steady state: |
| 29 |
|
| 30 |
1. For the maintainer tag in metadata, have a type attribute that can |
| 31 |
be developer, project, or proxy. |
| 32 |
|
| 33 |
2. Add a contacts tag in metadata that takes an email. |
| 34 |
|
| 35 |
3. Package without maintainers (individuals or projects - regardless |
| 36 |
of presence of aliases) get assigned to maintainer-needed and get |
| 37 |
treecleaned as usual. |
| 38 |
|
| 39 |
I'm also fine with normalizing this and just switching to a contact |
| 40 |
tag that can have a type of developer, project, proxy, or contact. |
| 41 |
That is a bigger change. However, it would probably simplify |
| 42 |
scripting and be a bit cleaner for the long-term. |
| 43 |
|
| 44 |
|
| 45 |
For the transition to the steady state: |
| 46 |
|
| 47 |
a. We generate a list of all current herds and email their aliases to |
| 48 |
see if they want to be converted to a non-maintainer alias, or be |
| 49 |
disbanded entirely. One reply to the email is enough to keep the |
| 50 |
alias around, no replies means retirement. |
| 51 |
|
| 52 |
b. Anybody in Gentoo can start a project already by following GLEP 39. |
| 53 |
It is encouraged for these projects to take over existing aliases |
| 54 |
where they feel it is appropriate. There is no need for all aliases |
| 55 |
to have a project - just ones that want some kind of structure (ie |
| 56 |
this is strictly voluntary). When this is done the project will |
| 57 |
remove the herd from metadata and add the project alias as a |
| 58 |
maintainer with the agreed-upon tagging. |
| 59 |
|
| 60 |
c. We generate a list of all current packages that do not have a |
| 61 |
maintainer (either one or more individuals or projects (NOT herds)). |
| 62 |
That gets posted so that individuals can claim them. I suggest not |
| 63 |
doing the usual treecleaning email since there could be a LOT of them. |
| 64 |
Or we could do it herd-by-herd over time to ease the load. |
| 65 |
|
| 66 |
d. We remove all herds from the existing packages. Where aliases were |
| 67 |
kept in (a) above they are converted to aliases with appropriate |
| 68 |
tagging. If no maintainer exists the package is handled per the |
| 69 |
result of (c). |
| 70 |
|
| 71 |
|
| 72 |
Comments, alternatives, etc? |
| 73 |
|
| 74 |
-- |
| 75 |
Rich |
Archives