Gentoo Archives: gentoo-dev

From: Dan Armak <danarmak@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Gentoo: State of the Union
Date: Sat, 29 Apr 2006 12:02:52
Message-Id: 200604291458.48191.danarmak@gentoo.org
In Reply to: [gentoo-dev] Gentoo: State of the Union by Ryan Phillips
1 On Friday 28 April 2006 20:14, Ryan Phillips wrote:
2 > __Problem: Live Tree__
3 >
4 > Having a live tree requires people to be perfect. People are not perfect
5 > and requiring it is ridiculous. I love having commits in my local tree
6 > within the hour, but having a stable and unstable branch makes a lot of
7 > sense.
8 >
9 > CVS doesn't do branching nor tags very well...
10 >
11 > __Problem: CVS__
12 >
13 > CVS is one of the worst application ever created. The portage tree needs
14 > to move to subversion. A lot of the problems within the project would be
15 > solved by using a better SCM system. The previous problems regarding the
16 > Live Tree and Developer Growth would be solved, IMHO, by just switching.
17 > Branches Work. Tags Work. Reverts work. Moves work. I don't see any
18 > reason not to use it. It just plain works.
19 >
20 > Projects (gentoo/bsd, embedded, hardened) could choose to keep their own
21 > branches of the portage tree and merge with trunk as needed. Projects
22 > could stick to traditional solutions like profiles if they so wished.
23 >
24 > Some will probably ask who will merge between branches. We can do that
25 > easily ourselves. If I think a package is good to go, then svn merge
26 > -r1123:1124 to the branch.
27
28 I'm very much in favor of moving to a new SCM, and I see how it could solve
29 many problems. But I don't understand how it could remove the need for a live
30 tree. Could you explain the new usage pattern you're suggesting here?
31
32 If there's no live tree (or live branch), then every commit has to be merged
33 from the 'incoming' branch or trunk where it is originally committed to
34 the 'outgoing' branch which is directly used by users, even for ~arch chages.
35 Is that really what you mean?
36
37 And this becomes a lot worse if you want to replace (at least some) KEYWORDS
38 with branches, and have to merge each change many times.
39
40 Meanwhile, if no-one is using trunk (or the 'incoming' branch) directly
41 (because it's not live), what is the benefit of leaving commits there for a
42 few hours? It won't help you find most problems.
43
44
45 Apart from having no live tree, though, I understand and like the model of
46 having:
47 - 'Incoming' (sandbox) branches where non-dev affiliates, and new devs, commit
48 things which are then reviewed by a full dev/mentor and merged into trunk.
49 - Branches replacing today's various overlays for devs (or projects, etc) and
50 anyone else we might welcome on g.o infrastructure (given per-branch commit
51 permissions).
52 - Short-lived branches to replace things that are today package.masked.
53 - Branches to replace various non-arch keywords and projects, like hardened
54 stuff, some server/ultrastable tree proposals, ...
55
56 --
57 Dan Armak
58 Gentoo Linux developer (KDE)
59 Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
60 Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD 0069 508D 9143 8D5F 8951