1 |
Hi |
2 |
|
3 |
As git is generally not best suited for large repositories, there are some |
4 |
ideas how to make it perform better with gentoo-x86. |
5 |
- horizontal partitioning - a'ka cutting history |
6 |
- vertical partitioning - splitting based on some categorization (not sure |
7 |
whether this was considered here, hence my mail). |
8 |
|
9 |
As cutting history have already been proposed here and received with mixed |
10 |
opinions, I'd like to suggest category based partitioning (divide and conquer |
11 |
approach FTW). |
12 |
Well, not really category-based... |
13 |
|
14 |
Let's look at tree - one thing can be said about each package - it belongs to |
15 |
some herd or (doesn't, and it's with status maintainer wanted or maintained by |
16 |
individual developers). |
17 |
So creating separate repository for each herd is the most obvious (and naive) |
18 |
idea. |
19 |
|
20 |
Pros are the following: |
21 |
- project members taking care of some herd (or belonging to herd?) receive |
22 |
(and have access) (only) to repository they are interested in, resulting in |
23 |
smaller pulls/pushes |
24 |
- some level of isolation - gives possibility to restrict access (for example: |
25 |
"only toolchain and arch teams allowed here") |
26 |
- some testing overlays could now just track their tree counterparts - merging |
27 |
stuff from testing to tree could be semi-automatic and trivial |
28 |
- alternative projects - like hardened - can just have separate branches when |
29 |
appropriate - for easy merges with "main tree" |
30 |
- profile can be (should be actually) separated in another repository and |
31 |
developed easier |
32 |
|
33 |
Some cons: |
34 |
- projects are now more dependant on other projects and its responsiveness, |
35 |
unless access is granted to all repositories for every developer |
36 |
- needs some basic tools to 'glue' final repository and ready it for rsync |
37 |
- possibly needs better multiple repositories support in Portage (not sure |
38 |
though) |
39 |
- profile no longer there |
40 |
- to fully benefit from git - robbat2 would need to propose his slim manifest |
41 |
format as GLEP (or in case of lack of time - quite possible - get someone else |
42 |
to do it) and get it implemented by someone. |
43 |
- probably not easy way to migrate from monolithic gentoo-x86 to split sub- |
44 |
repositories retaining complete history |
45 |
- not settled yet what to do with orphaned/proxy maintained packages and herd- |
46 |
switching |
47 |
|
48 |
Zac, I'm CC-ing you here, I hope you don't mind. Sorry, but your input is too |
49 |
valuable here :) |
50 |
|
51 |
I guess I could, and find someone as well to, do some tedious and repetitive |
52 |
work in that manner. |
53 |
|
54 |
-- |
55 |
regards |
56 |
MM |