Gentoo Archives: gentoo-dev

From: George Shapovalov <georges@×××××××××××.edu>
To: Gentoo Dev <gentoo-dev@g.o>
Subject: [gentoo-dev] Unstable branch proposal - second round
Date: Sat, 16 Mar 2002 13:45:52
Message-Id: 200203161942.LAA07376@chamber.cco.caltech.edu
1 Hi All.
2
3 I just looked again through the recent thread and here are some thoughts I
4 would like to throw out.
5 The thread did not see that much of activity and I thought that timing was
6 not right - during the feature freeze right before 1.0 release. Then I gave
7 it a second thought and here are a few things I would like to bring here. I
8 will try to summarise the previous discussion and then propose some stuff
9 which if accepted will require a minor addition to existing functionality and
10 may even go in the tree before release (or to 1.x version).
11
12 Now to the issue.
13 Technically I would not call the proposed an "unstable branch". The core
14 which is a portage system and supporting infrastructure is going to stay the
15 same, there has been no call to fork that as far as I can tell (and I am not
16 about to do that either). The call was for producing new ebuild submission
17 system.
18 At present gentoo definitely allows submission of new ebuilds - you just have
19 to go to bugs.gentoo.org and submit an ebuild as described in manual, then it
20 gets reviewed by core developer and goes into /usr/portage/incoming/ and
21 later gets incorporated into the portage tree.
22 While a very sound submission protocol it is not very scalable if ebuild
23 submissions are expected to grow significantly. In such case a decentralised
24 submission/review schema is desired.
25
26 One proposed way of doing this was to setup a self-managed "mirror", which
27 should accept all packages from developers but keep them local. New
28 submissions will get reviewed by community and later manually incorporated
29 into the main tree by core developers.
30 While this allows better exposure of new submissions it does not prevent the
31 bottleneck - core developers will be just as occupied. Than self-managed
32 sound like a way to start a big mess unless somebody is going to spend a lot
33 of time actively maintaining thing, compiling lists of a "worthy", "confirmed
34 by majority", etc.. ebuilds. And actively pushing them to the core group.
35 Also having to worry about separate system incarnation looks like a
36 possibility to start a fork where you might avoid doing so. After all these
37 systems will have different requirements.
38
39 Another possibility is to use the same infrastructure, but add new
40 specificator to the package name, which will mark it as "unstable". Allow
41 unstable ebuilds to appear in the main tree but these will be installed (and
42 reported) only if you use special flag (for example --allow-unstable) with
43 emerge (ebuild as a low-level utility I guess should just do whatever you ask
44 it to). After all this is similar to what people do now with not yet
45 incorporated ebuilds.
46 Users of unstable ebuilds can and are requested to report on
47 usability/stability of an ebuild by setting some flag in the package dir or
48 somewhere in the database, which should be counted when user rsyncs again.
49 Certain policy can be set, so that for example packages accumulating enough
50 voices should automatically be granted for example "confirmed" status. There
51 might be additional layer of (even manual) check through which the package
52 should go to get "approved" status (and the removal of specificator form
53 ebuild name).
54 I am apparently thinking in favour of this one as it seems things can be
55 setup more cleanly this way (avoiding any reason for possible forking) while
56 allowing everybody to have easier access to all functionality. Users can
57 choose to stick with "approved" packages if stability is of most concern,
58 "confirmed" if some more functionality is desired or even "unstable" to
59 access all packages (and of course anybody anytime can force-install any
60 package). To provide this functionality emerge can check make.conf for
61 -allow-status flag for example. The tree can even be synchronised on user
62 machine according to set stability level.
63 The main benefit of setting up something along these lines is that newly
64 submitted ebuilds get much broader attention. Especially recalling numerous
65 calls for setting up the list of new ebuild submissions so that newcomers can
66 start to actively contribute to the system, while allowing "core" people to
67 concentrate on essential stuff.
68
69 George

Replies

Subject Author
Re: [gentoo-dev] Unstable branch proposal - second round George Shapovalov <georges@×××××××××××.edu>
[gentoo-dev] Re: Unstable branch proposal - second round Troy Dack <troy@××××××.com>