| 1 |
On 09/27/14 17:35, Tom Wijsman wrote: |
| 2 |
> On Sat, 27 Sep 2014 06:25:28 -0400 |
| 3 |
> Rich Freeman <rich0@g.o> wrote: |
| 4 |
> |
| 5 |
>> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers <jer@g.o> |
| 6 |
>> wrote: |
| 7 |
>>> Right now, CC'ing a single alias is inconvenient, but under your |
| 8 |
>>> proposal, you might need to CC a dozen or more people instead of |
| 9 |
>>> that alias. |
| 10 |
>>> |
| 11 |
>> That is incorrect. Herds would be replaced with projects, not with |
| 12 |
>> lists of individual (non-)maintainers. |
| 13 |
>> |
| 14 |
>> I don't think that anybody thinks that having groups of devs isn't |
| 15 |
>> useful. The problem is that we have two different mechanisms for |
| 16 |
>> having groups of people, and one of them seems to make more sense than |
| 17 |
>> the other. |
| 18 |
>> |
| 19 |
>> Answer this: 5 developers want to maintain a group of packages |
| 20 |
>> together. Should they form a herd, or a project? Under what |
| 21 |
>> circumstances should they choose one vs the other? |
| 22 |
>> |
| 23 |
>> I don't think the distinction is particularly useful, and projects at |
| 24 |
>> least have a straightforward governance model. |
| 25 |
>> |
| 26 |
>> -- |
| 27 |
>> Rich |
| 28 |
>> |
| 29 |
> Herds cannot be replaced by projects, because projects can contain |
| 30 |
> multiple herds; iotw, there's no one-to-one mapping between them. |
| 31 |
The hardened project has two herds: hardened and hardened-kernel, the |
| 32 |
former for toolchain related stuff and the latter for the kernel. We |
| 33 |
really need to keep that distinction. So mapping herds to projects |
| 34 |
doesn't work. But, mapping hardened/hardened-kernel to our |
| 35 |
*subprojects* structure does. Perhaps that might be a more natural |
| 36 |
solution in general, not just for hardened. |
| 37 |
|
| 38 |
We might proceed by associating each herd to a project, and then letting |
| 39 |
them decide whether to absorb the herd(s) into their project level, or |
| 40 |
break it down to subprojects. So as another example, ppc and ppc64 |
| 41 |
teams are merging into one team (powerpc) with one lead (currently |
| 42 |
jmorgan). There also we want to keep two herds for the two different |
| 43 |
arches for keywording/stabilizing requests. If we just say "ppc and |
| 44 |
ppc64 herds belong to powerpc team", then it will be easy to change |
| 45 |
"herd" to "subproject" requiring nothing more than just a webpage put up |
| 46 |
if it doesn't already exist. |
| 47 |
|
| 48 |
> |
| 49 |
> I don't think having multiple mechanisms to form groups is a problem; |
| 50 |
> from my previous paragraph, it becomes clear that it is a solution. |
| 51 |
> |
| 52 |
> Answer: The project model has some concepts that herds do not have. |
| 53 |
> |
| 54 |
> I don't think discussing this is useful, projects are documented. |
| 55 |
> |
| 56 |
|
| 57 |
|
| 58 |
-- |
| 59 |
Anthony G. Basile, Ph.D. |
| 60 |
Gentoo Linux Developer [Hardened] |
| 61 |
E-Mail : blueness@g.o |
| 62 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 63 |
GnuPG ID : F52D4BBA |
Archives