1 |
On Saturday 11 April 2009, Maciej Mrozowski wrote: |
2 |
> Let's look at tree - one thing can be said about each package - it |
3 |
> belongs to some herd or (doesn't, and it's with status maintainer |
4 |
> wanted or maintained by individual developers). |
5 |
> So creating separate repository for each herd is the most obvious |
6 |
> (and naive) idea. |
7 |
> |
8 |
> Pros are the following: |
9 |
> - project members taking care of some herd (or belonging to herd?) |
10 |
> receive (and have access) (only) to repository they are interested |
11 |
> in, resulting in smaller pulls/pushes |
12 |
> - some level of isolation - gives possibility to restrict access (for |
13 |
> example: "only toolchain and arch teams allowed here") |
14 |
> - some testing overlays could now just track their tree counterparts |
15 |
> - merging stuff from testing to tree could be semi-automatic and |
16 |
> trivial - alternative projects - like hardened - can just have |
17 |
> separate branches when appropriate - for easy merges with "main tree" |
18 |
|
19 |
Why would hardened have an easier job branching off multiple single |
20 |
repos than one large repository? |
21 |
|
22 |
|
23 |
> - profile can be (should be actually) separated in another repository |
24 |
> and developed easier |
25 |
|
26 |
The whole modle of profiles (and keywords, for that matter) is worked |
27 |
out so we do not need branches. We keep ebuilds in one tree and define |
28 |
visibility for the "branches" (from a user's PoV). Do you really think |
29 |
actually branching off makes it easier for anyone? Who would push |
30 |
changes to the 50.. something profiles? Does ~sh get more usable if |
31 |
maintainers don't push trivial updates to that branch anymore? |
32 |
|
33 |
> Some cons: |
34 |
> - projects are now more dependant on other projects and its |
35 |
> responsiveness, unless access is granted to all repositories for |
36 |
> every developer - needs some basic tools to 'glue' final repository |
37 |
> and ready it for rsync - possibly needs better multiple repositories |
38 |
> support in Portage (not sure though) |
39 |
> - profile no longer there |
40 |
> - to fully benefit from git - robbat2 would need to propose his slim |
41 |
> manifest format as GLEP (or in case of lack of time - quite possible |
42 |
> - get someone else to do it) and get it implemented by someone. |
43 |
> - probably not easy way to migrate from monolithic gentoo-x86 to |
44 |
> split sub- repositories retaining complete history |
45 |
> - not settled yet what to do with orphaned/proxy maintained packages |
46 |
> and herd- switching |
47 |
|
48 |
We have been over the "splitting" by category/feature/herd part before |
49 |
and had not reached a consensus. |
50 |
|
51 |
Personally, I do not see overall tree QA improving. |
52 |
Long before I joined Gentoo a decision was made deliberately to give |
53 |
write access for each directory to each developer. And it allows me to |
54 |
responsibly fix bugs that others cannot currently handle, and I can |
55 |
tell others to commit fixes to the ebuilds that carry my name in |
56 |
metadata.xml. It also allows for easy tree migration efforts (big |
57 |
renames, or the recent use dependency changes), keywordings and it |
58 |
allows the security team to mess around with other people's kittens if |
59 |
they slack. |
60 |
|
61 |
|
62 |
|
63 |
Robert |