| 1 |
On Sat, 11 Apr 2009 14:40:27 +0200 |
| 2 |
Maciej Mrozowski <reavertm@××××××.fm> wrote: |
| 3 |
|
| 4 |
> Let's look at tree - one thing can be said about each package - it belongs to |
| 5 |
> some herd or (doesn't, and it's with status maintainer wanted or maintained by |
| 6 |
> individual developers). |
| 7 |
> So creating separate repository for each herd is the most obvious (and naive) |
| 8 |
> idea. |
| 9 |
|
| 10 |
While this may seem like a good idea for those projects and herds that are |
| 11 |
well defined, well-oiled machines, I can count the number of these projects |
| 12 |
in Gentoo on one hand. |
| 13 |
|
| 14 |
> Pros are the following: |
| 15 |
> - project members taking care of some herd (or belonging to herd?) receive |
| 16 |
> (and have access) (only) to repository they are interested in, resulting in |
| 17 |
> smaller pulls/pushes |
| 18 |
|
| 19 |
...and isolating them from the rest of the tree, as well as the rest of |
| 20 |
developers from them. |
| 21 |
|
| 22 |
> - some level of isolation - gives possibility to restrict access (for example: |
| 23 |
> "only toolchain and arch teams allowed here") |
| 24 |
|
| 25 |
This is counter to the ideals behind Gentoo, blah blah. In reality, if |
| 26 |
someone screws up toolchain stuff, they only do it once. |
| 27 |
|
| 28 |
> - profile can be (should be actually) separated in another repository and |
| 29 |
> developed easier |
| 30 |
|
| 31 |
Repositories, when split, are best split into atomic units. Separating |
| 32 |
profiles from packages, given their dependence on each other, is a |
| 33 |
non-starter. |
| 34 |
|
| 35 |
I'm not sure what we'd do with eclasses either. Obviously they |
| 36 |
can't be split into herds, but they need to be updated with the ebuilds |
| 37 |
themselves. |
| 38 |
|
| 39 |
In Gentoo development the atomic unit is the repo itself, for better or worse. |
| 40 |
|
| 41 |
> Some cons: |
| 42 |
> - projects are now more dependant on other projects and its responsiveness, |
| 43 |
> unless access is granted to all repositories for every developer |
| 44 |
|
| 45 |
Which is one of the biggest problems we already have IMHO. |
| 46 |
|
| 47 |
> - not settled yet what to do with orphaned/proxy maintained packages and herd- |
| 48 |
> switching |
| 49 |
|
| 50 |
We have ~800 maintainer-needed packages right now. We have multitudes more |
| 51 |
that belong to herds with no real people in them, or have unresponsive |
| 52 |
maintainers. Cutting them off from the rest of the tree by making them |
| 53 |
harder to get to isn't going to improve things. |
| 54 |
|
| 55 |
|
| 56 |
|
| 57 |
-- |
| 58 |
gcc-porting, by design, by neglect |
| 59 |
treecleaner, for a fact or just for effect |
| 60 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
Archives