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 |