| 1 |
On Sat, 27 Sep 2014 17:54:48 -0400 |
| 2 |
"Anthony G. Basile" <blueness@g.o> wrote: |
| 3 |
|
| 4 |
> The hardened project has two herds: hardened and hardened-kernel, the |
| 5 |
> former for toolchain related stuff and the latter for the kernel. We |
| 6 |
> really need to keep that distinction. So mapping herds to projects |
| 7 |
> doesn't work. But, mapping hardened/hardened-kernel to our |
| 8 |
> *subprojects* structure does. Perhaps that might be a more natural |
| 9 |
> solution in general, not just for hardened. |
| 10 |
> |
| 11 |
> We might proceed by associating each herd to a project, and then |
| 12 |
> letting them decide whether to absorb the herd(s) into their project |
| 13 |
> level, or break it down to subprojects. So as another example, ppc |
| 14 |
> and ppc64 teams are merging into one team (powerpc) with one lead |
| 15 |
> (currently jmorgan). There also we want to keep two herds for the |
| 16 |
> two different arches for keywording/stabilizing requests. If we just |
| 17 |
> say "ppc and ppc64 herds belong to powerpc team", then it will be |
| 18 |
> easy to change "herd" to "subproject" requiring nothing more than |
| 19 |
> just a webpage put up if it doesn't already exist. |
| 20 |
|
| 21 |
Yes, if you do create a one-on-one mapping then it becomes possible. |
| 22 |
The question becomes "does every herd want to become a (sub)project?". |
| 23 |
|
| 24 |
Ideally, they should! Theoretically, there is no problem. Practically, |
| 25 |
for some herds it'll involve extra work setting up the project related |
| 26 |
stuff and so on when there is no need for it. |
| 27 |
|
| 28 |
Example: If I were to create a MATE herd, that doesn't mean I want a |
| 29 |
MATE project; documentation wise, the Gentoo Wiki article suffices. |
Archives