1 |
Great, we will be a Debian Want a be! |
2 |
On Mon, 2002-03-25 at 06:23, Troy Dack wrote: |
3 |
> ( new post @ bottom, original left in for continuity ... ) |
4 |
> |
5 |
> On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this: |
6 |
> |
7 |
> > Hi All. |
8 |
> > |
9 |
> > I just looked again through the recent thread and here are some thoughts I |
10 |
> > would like to throw out. |
11 |
> > The thread did not see that much of activity and I thought that timing was |
12 |
> > not right - during the feature freeze right before 1.0 release. Then I |
13 |
> > gave it a second thought and here are a few things I would like to bring |
14 |
> > here. I will try to summarise the previous discussion and then propose |
15 |
> > some stuff which if accepted will require a minor addition to existing |
16 |
> > functionality and may even go in the tree before release (or to 1.x |
17 |
> > version). |
18 |
> > |
19 |
> > Now to the issue. |
20 |
> > Technically I would not call the proposed an "unstable branch". The core |
21 |
> > which is a portage system and supporting infrastructure is going to stay |
22 |
> > the same, there has been no call to fork that as far as I can tell (and I |
23 |
> > am not about to do that either). The call was for producing new ebuild |
24 |
> > submission system. |
25 |
> > At present gentoo definitely allows submission of new ebuilds - you just |
26 |
> > have to go to bugs.gentoo.org and submit an ebuild as described in manual, |
27 |
> > then it gets reviewed by core developer and goes into |
28 |
> > /usr/portage/incoming/ and later gets incorporated into the portage tree. |
29 |
> > While a very sound submission protocol it is not very scalable if ebuild |
30 |
> > submissions are expected to grow significantly. In such case a |
31 |
> > decentralised submission/review schema is desired. |
32 |
> > |
33 |
> > One proposed way of doing this was to setup a self-managed "mirror", which |
34 |
> > should accept all packages from developers but keep them local. New |
35 |
> > submissions will get reviewed by community and later manually incorporated |
36 |
> > into the main tree by core developers. |
37 |
> > While this allows better exposure of new submissions it does not prevent |
38 |
> > the bottleneck - core developers will be just as occupied. Than |
39 |
> > self-managed sound like a way to start a big mess unless somebody is going |
40 |
> > to spend a lot of time actively maintaining thing, compiling lists of a |
41 |
> > "worthy", "confirmed by majority", etc.. ebuilds. And actively pushing |
42 |
> > them to the core group. Also having to worry about separate system |
43 |
> > incarnation looks like a possibility to start a fork where you might avoid |
44 |
> > doing so. After all these systems will have different requirements. |
45 |
> > |
46 |
> > Another possibility is to use the same infrastructure, but add new |
47 |
> > specificator to the package name, which will mark it as "unstable". Allow |
48 |
> > unstable ebuilds to appear in the main tree but these will be installed |
49 |
> > (and reported) only if you use special flag (for example --allow-unstable) |
50 |
> > with emerge (ebuild as a low-level utility I guess should just do whatever |
51 |
> > you ask it to). After all this is similar to what people do now with not |
52 |
> > yet incorporated ebuilds. |
53 |
> > Users of unstable ebuilds can and are requested to report on |
54 |
> > usability/stability of an ebuild by setting some flag in the package dir |
55 |
> > or somewhere in the database, which should be counted when user rsyncs |
56 |
> > again. Certain policy can be set, so that for example packages |
57 |
> > accumulating enough voices should automatically be granted for example |
58 |
> > "confirmed" status. There might be additional layer of (even manual) check |
59 |
> > through which the package should go to get "approved" status (and the |
60 |
> > removal of specificator form ebuild name). |
61 |
> > I am apparently thinking in favour of this one as it seems things can be |
62 |
> > setup more cleanly this way (avoiding any reason for possible forking) |
63 |
> > while allowing everybody to have easier access to all functionality. Users |
64 |
> > can choose to stick with "approved" packages if stability is of most |
65 |
> > concern, "confirmed" if some more functionality is desired or even |
66 |
> > "unstable" to access all packages (and of course anybody anytime can |
67 |
> > force-install any package). To provide this functionality emerge can check |
68 |
> > make.conf for -allow-status flag for example. The tree can even be |
69 |
> > synchronised on user machine according to set stability level. |
70 |
> > The main benefit of setting up something along these lines is that newly |
71 |
> > submitted ebuilds get much broader attention. Especially recalling |
72 |
> > numerous calls for setting up the list of new ebuild submissions so that |
73 |
> > newcomers can start to actively contribute to the system, while allowing |
74 |
> > "core" people to concentrate on essential stuff. |
75 |
> > |
76 |
> > George |
77 |
> |
78 |
> George, |
79 |
> After reading the messages in this thread (particularly the last two |
80 |
> posted by you) I'd like to say that I agree with you and to add a couple of |
81 |
> thoughts of my own. |
82 |
> |
83 |
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made |
84 |
> easily available to all gentoo users -- keeping one interface for |
85 |
> submission is a good idea. |
86 |
> |
87 |
> However instead of (as well as) your multiple package state levels how |
88 |
> about this (this is all just hypthesis, I don't know if it is possible, I |
89 |
> don't know enough about all the tools used): |
90 |
> |
91 |
> Multiple cvs branches along the lines of this: |
92 |
> |
93 |
> Testing Branch - primarily for use by developers. |
94 |
> - new ebuilds from bugs.gentoo.org come in here |
95 |
> - If there is no activity on an ebuild (it's bug) |
96 |
> for 14 days it get's moved to Unstable |
97 |
> |
98 |
> Unstable Branch - ebuilds that have made it out of testing and *should* |
99 |
> work for most users |
100 |
> - flagged as Stable after 28 days of nil activity on the bug |
101 |
> - need to be reviewd by gentoo dev team before getting into |
102 |
> Stable |
103 |
> |
104 |
> Stable Branch - ebuilds that have made it out of Unstable and are suitable |
105 |
> for general consupmtion. |
106 |
> - the beginning of the "next" gentoo release branch |
107 |
> |
108 |
> Release Branch - ebuilds that are the *current* release of gentoo |
109 |
> - no changes (except critical security and bug fixes) to |
110 |
> be made to this branch |
111 |
> |
112 |
> My proposal to integrate this into the portage system and give users a |
113 |
> means of selecting which branch they wish to rsync against. |
114 |
> |
115 |
> eg: |
116 |
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync |
117 |
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable |
118 |
> |
119 |
> or |
120 |
> |
121 |
> root@gentoobox # emerge rsync |
122 |
> ... updating /usr/portage/release from cvs.gentoo.org |
123 |
> |
124 |
> ie: emerge defaults to using the release branch. |
125 |
> |
126 |
> It may mean a slightly larger /usr/portage for some users (particularly |
127 |
> devs), but I think it is needed to reduce the rash of -rX ebuilds that are |
128 |
> coming out as the developers _react_ to all the problems that are occuring. |
129 |
> |
130 |
> This will also allow new users to install a version of gentoo that will |
131 |
> actually work first go. Then as they get comfortable with the system they |
132 |
> can start to experiment, first with Stable ebuilds and then move on to |
133 |
> Unstable and become part of the development process. |
134 |
> |
135 |
> Just my $0.02, either way I'm still going to continue to use gentoo, it is |
136 |
> by far the best way to learn about and use linux going. |
137 |
> |
138 |
> -- |
139 |
> Troy Dack |
140 |
> http://linuxserver.tkdack.com |
141 |
> |
142 |
> "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and |
143 |
> the Ugly)." (By Matt Welsh) |
144 |
> |
145 |
> _______________________________________________ |
146 |
> gentoo-dev mailing list |
147 |
> gentoo-dev@g.o |
148 |
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev |