| 1 |
On Sat, Oct 28, 2006 at 08:11:37AM +0200, George Shapovalov wrote: |
| 2 |
> One of the reasons herds were introduced was to explicitly see what packages |
| 3 |
> lack maintenance. It is possible for the ebuild to be in the herd, but be |
| 4 |
> supported by the developer not on the herd. See the <role> tag. Also, there |
| 5 |
> can be one-dev herds. |
| 6 |
I have a number of specialized packages that I maintain, such as |
| 7 |
sys-block/qla-fc-firmware, that cannot be classified as any existing |
| 8 |
herd, and are specialized enough inventing a new herd for them would not |
| 9 |
really help. |
| 10 |
|
| 11 |
The point of herds as I saw it originally, was to capture packages that |
| 12 |
do NOT have any explicit maintainer. |
| 13 |
|
| 14 |
I've also lost bugs in the past on my packages where I'm not in the |
| 15 |
herd, but I am the actual maintainer, because the bug was assigned to |
| 16 |
the herd alias, and I didn't see it until several months later, when |
| 17 |
somebody finally asked me directly, or reassigned it to me. |
| 18 |
|
| 19 |
For no-herd, I say we should add it to the valid herds list, and |
| 20 |
validate all metadata files, and require that if no-herd is used, an |
| 21 |
explicit maintainer is present (using the active list of developers). |
| 22 |
|
| 23 |
-- |
| 24 |
Robin Hugh Johnson |
| 25 |
E-Mail : robbat2@g.o |
| 26 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives