1 |
On Sat, 2004-10-09 at 18:25 +0100, Ciaran McCreesh wrote: |
2 |
> On Sat, 09 Oct 2004 16:54:29 +0200 foser <foser@g.o> wrote: |
3 |
> | On Sat, 2004-10-09 at 14:56 +0100, Ciaran McCreesh wrote: |
4 |
> | > On Sat, 09 Oct 2004 15:33:19 +0200 foser <foser@g.o> wrote: |
5 |
> | > | Every package is in some form a subset of a category of packages |
6 |
> | > |
7 |
> | > Not really, hence why solar's suggestion (which is just a |
8 |
> | > formalisation of what we're doing anyway) is such a good idea. |
9 |
> | |
10 |
> | Well, this gets to be a yes/no thread. But I personally do not believe |
11 |
> | there are packages that cannot be categorized in meaningful way on |
12 |
> | some common denominator with other packages (read : herd). Granted, a |
13 |
> | herd may not exist yet, but thats something else. |
14 |
> |
15 |
> Well, that's the thing... You *could* go and create a bunch of arbitrary |
16 |
> herds to cover things. But take, for example, er... dev-util/txt2regex. |
17 |
> I think you'd have a hard time finding a herd for that, since there's no |
18 |
> particular identifiable group of people that use both this and a half |
19 |
> dozen or so other misc apps. Plus, it's such a trivial easy-to-maintain |
20 |
> package that it's not worth the effort of finding additional maintainers |
21 |
> and co-ordinating them. Some things really don't need a team behind |
22 |
> them... |
23 |
|
24 |
I don't say these things need a 'team behind them' when they are being |
25 |
maintained by some individual, i do say that they need something to fall |
26 |
back upon when the maintainer disappears. Already certain 'no-herd'-ed |
27 |
ebuilds with a single maintainer are unmaintained because the maintainer |
28 |
went inactive. The essence is to always have some group responsible for |
29 |
every ebuild in the tree. |
30 |
|
31 |
This is not about making a difference when the maintainer is still |
32 |
around, but a way to guarantee continuity. In this case I can imagine a |
33 |
nice herd dubbed shell-tools or something where this & other |
34 |
unidentifiable commandline utils can be grouped together. |
35 |
|
36 |
- foser |