Gentoo Archives: gentoo-scm

From: Robert Buchholz <rbu@g.o>
To: gentoo-scm@l.g.o
Cc: Maciej Mrozowski <reavertm@××××××.fm>, Zac Medico <zmedico@g.o>
Subject: Re: [gentoo-scm] Splitting gentoo-x86 repository for easier consumption
Date: Sat, 11 Apr 2009 15:47:13
Message-Id: 200904111747.11614.rbu@gentoo.org
In Reply to: [gentoo-scm] Splitting gentoo-x86 repository for easier consumption by Maciej Mrozowski
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

Attachments

File name MIME type
signature.asc application/pgp-signature