* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
@ 2002-03-25 14:57 ` Aaron Cohen
2002-03-28 3:22 ` Aaron Cohen
2002-03-26 3:36 ` George Shapovalov
2002-03-29 23:40 ` Chris Johnson
2 siblings, 1 reply; 25+ messages in thread
From: Aaron Cohen @ 2002-03-25 14:57 UTC (permalink / raw
To: gentoo-dev
Great, we will be a Debian Want a be!
On Mon, 2002-03-25 at 06:23, Troy Dack wrote:
> ( new post @ bottom, original left in for continuity ... )
>
> On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:
>
> > Hi All.
> >
> > I just looked again through the recent thread and here are some thoughts I
> > would like to throw out.
> > The thread did not see that much of activity and I thought that timing was
> > not right - during the feature freeze right before 1.0 release. Then I
> > gave it a second thought and here are a few things I would like to bring
> > here. I will try to summarise the previous discussion and then propose
> > some stuff which if accepted will require a minor addition to existing
> > functionality and may even go in the tree before release (or to 1.x
> > version).
> >
> > Now to the issue.
> > Technically I would not call the proposed an "unstable branch". The core
> > which is a portage system and supporting infrastructure is going to stay
> > the same, there has been no call to fork that as far as I can tell (and I
> > am not about to do that either). The call was for producing new ebuild
> > submission system.
> > At present gentoo definitely allows submission of new ebuilds - you just
> > have to go to bugs.gentoo.org and submit an ebuild as described in manual,
> > then it gets reviewed by core developer and goes into
> > /usr/portage/incoming/ and later gets incorporated into the portage tree.
> > While a very sound submission protocol it is not very scalable if ebuild
> > submissions are expected to grow significantly. In such case a
> > decentralised submission/review schema is desired.
> >
> > One proposed way of doing this was to setup a self-managed "mirror", which
> > should accept all packages from developers but keep them local. New
> > submissions will get reviewed by community and later manually incorporated
> > into the main tree by core developers.
> > While this allows better exposure of new submissions it does not prevent
> > the bottleneck - core developers will be just as occupied. Than
> > self-managed sound like a way to start a big mess unless somebody is going
> > to spend a lot of time actively maintaining thing, compiling lists of a
> > "worthy", "confirmed by majority", etc.. ebuilds. And actively pushing
> > them to the core group. Also having to worry about separate system
> > incarnation looks like a possibility to start a fork where you might avoid
> > doing so. After all these systems will have different requirements.
> >
> > Another possibility is to use the same infrastructure, but add new
> > specificator to the package name, which will mark it as "unstable". Allow
> > unstable ebuilds to appear in the main tree but these will be installed
> > (and reported) only if you use special flag (for example --allow-unstable)
> > with emerge (ebuild as a low-level utility I guess should just do whatever
> > you ask it to). After all this is similar to what people do now with not
> > yet incorporated ebuilds.
> > Users of unstable ebuilds can and are requested to report on
> > usability/stability of an ebuild by setting some flag in the package dir
> > or somewhere in the database, which should be counted when user rsyncs
> > again. Certain policy can be set, so that for example packages
> > accumulating enough voices should automatically be granted for example
> > "confirmed" status. There might be additional layer of (even manual) check
> > through which the package should go to get "approved" status (and the
> > removal of specificator form ebuild name).
> > I am apparently thinking in favour of this one as it seems things can be
> > setup more cleanly this way (avoiding any reason for possible forking)
> > while allowing everybody to have easier access to all functionality. Users
> > can choose to stick with "approved" packages if stability is of most
> > concern, "confirmed" if some more functionality is desired or even
> > "unstable" to access all packages (and of course anybody anytime can
> > force-install any package). To provide this functionality emerge can check
> > make.conf for -allow-status flag for example. The tree can even be
> > synchronised on user machine according to set stability level.
> > The main benefit of setting up something along these lines is that newly
> > submitted ebuilds get much broader attention. Especially recalling
> > numerous calls for setting up the list of new ebuild submissions so that
> > newcomers can start to actively contribute to the system, while allowing
> > "core" people to concentrate on essential stuff.
> >
> > George
>
> George,
> After reading the messages in this thread (particularly the last two
> posted by you) I'd like to say that I agree with you and to add a couple of
> thoughts of my own.
>
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made
> easily available to all gentoo users -- keeping one interface for
> submission is a good idea.
>
> However instead of (as well as) your multiple package state levels how
> about this (this is all just hypthesis, I don't know if it is possible, I
> don't know enough about all the tools used):
>
> Multiple cvs branches along the lines of this:
>
> Testing Branch - primarily for use by developers.
> - new ebuilds from bugs.gentoo.org come in here
> - If there is no activity on an ebuild (it's bug)
> for 14 days it get's moved to Unstable
>
> Unstable Branch - ebuilds that have made it out of testing and *should*
> work for most users
> - flagged as Stable after 28 days of nil activity on the bug
> - need to be reviewd by gentoo dev team before getting into
> Stable
>
> Stable Branch - ebuilds that have made it out of Unstable and are suitable
> for general consupmtion.
> - the beginning of the "next" gentoo release branch
>
> Release Branch - ebuilds that are the *current* release of gentoo
> - no changes (except critical security and bug fixes) to
> be made to this branch
>
> My proposal to integrate this into the portage system and give users a
> means of selecting which branch they wish to rsync against.
>
> eg:
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
>
> or
>
> root@gentoobox # emerge rsync
> ... updating /usr/portage/release from cvs.gentoo.org
>
> ie: emerge defaults to using the release branch.
>
> It may mean a slightly larger /usr/portage for some users (particularly
> devs), but I think it is needed to reduce the rash of -rX ebuilds that are
> coming out as the developers _react_ to all the problems that are occuring.
>
> This will also allow new users to install a version of gentoo that will
> actually work first go. Then as they get comfortable with the system they
> can start to experiment, first with Stable ebuilds and then move on to
> Unstable and become part of the development process.
>
> Just my $0.02, either way I'm still going to continue to use gentoo, it is
> by far the best way to learn about and use linux going.
>
> --
> Troy Dack
> http://linuxserver.tkdack.com
>
> "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> the Ugly)." (By Matt Welsh)
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-25 14:57 ` Aaron Cohen
@ 2002-03-28 3:22 ` Aaron Cohen
2002-03-28 6:52 ` George Shapovalov
0 siblings, 1 reply; 25+ messages in thread
From: Aaron Cohen @ 2002-03-28 3:22 UTC (permalink / raw
To: gentoo-dev
It sounds like a good idea!
On Mon, 2002-03-25 at 09:57, Aaron Cohen wrote:
> Great, we will be a Debian Want a be!
> On Mon, 2002-03-25 at 06:23, Troy Dack wrote:
> > ( new post @ bottom, original left in for continuity ... )
> >
> > On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:
> >
> > > Hi All.
> > >
> > > I just looked again through the recent thread and here are some thoughts I
> > > would like to throw out.
> > > The thread did not see that much of activity and I thought that timing was
> > > not right - during the feature freeze right before 1.0 release. Then I
> > > gave it a second thought and here are a few things I would like to bring
> > > here. I will try to summarise the previous discussion and then propose
> > > some stuff which if accepted will require a minor addition to existing
> > > functionality and may even go in the tree before release (or to 1.x
> > > version).
> > >
> > > Now to the issue.
> > > Technically I would not call the proposed an "unstable branch". The core
> > > which is a portage system and supporting infrastructure is going to stay
> > > the same, there has been no call to fork that as far as I can tell (and I
> > > am not about to do that either). The call was for producing new ebuild
> > > submission system.
> > > At present gentoo definitely allows submission of new ebuilds - you just
> > > have to go to bugs.gentoo.org and submit an ebuild as described in manual,
> > > then it gets reviewed by core developer and goes into
> > > /usr/portage/incoming/ and later gets incorporated into the portage tree.
> > > While a very sound submission protocol it is not very scalable if ebuild
> > > submissions are expected to grow significantly. In such case a
> > > decentralised submission/review schema is desired.
> > >
> > > One proposed way of doing this was to setup a self-managed "mirror", which
> > > should accept all packages from developers but keep them local. New
> > > submissions will get reviewed by community and later manually incorporated
> > > into the main tree by core developers.
> > > While this allows better exposure of new submissions it does not prevent
> > > the bottleneck - core developers will be just as occupied. Than
> > > self-managed sound like a way to start a big mess unless somebody is going
> > > to spend a lot of time actively maintaining thing, compiling lists of a
> > > "worthy", "confirmed by majority", etc.. ebuilds. And actively pushing
> > > them to the core group. Also having to worry about separate system
> > > incarnation looks like a possibility to start a fork where you might avoid
> > > doing so. After all these systems will have different requirements.
> > >
> > > Another possibility is to use the same infrastructure, but add new
> > > specificator to the package name, which will mark it as "unstable". Allow
> > > unstable ebuilds to appear in the main tree but these will be installed
> > > (and reported) only if you use special flag (for example --allow-unstable)
> > > with emerge (ebuild as a low-level utility I guess should just do whatever
> > > you ask it to). After all this is similar to what people do now with not
> > > yet incorporated ebuilds.
> > > Users of unstable ebuilds can and are requested to report on
> > > usability/stability of an ebuild by setting some flag in the package dir
> > > or somewhere in the database, which should be counted when user rsyncs
> > > again. Certain policy can be set, so that for example packages
> > > accumulating enough voices should automatically be granted for example
> > > "confirmed" status. There might be additional layer of (even manual) check
> > > through which the package should go to get "approved" status (and the
> > > removal of specificator form ebuild name).
> > > I am apparently thinking in favour of this one as it seems things can be
> > > setup more cleanly this way (avoiding any reason for possible forking)
> > > while allowing everybody to have easier access to all functionality. Users
> > > can choose to stick with "approved" packages if stability is of most
> > > concern, "confirmed" if some more functionality is desired or even
> > > "unstable" to access all packages (and of course anybody anytime can
> > > force-install any package). To provide this functionality emerge can check
> > > make.conf for -allow-status flag for example. The tree can even be
> > > synchronised on user machine according to set stability level.
> > > The main benefit of setting up something along these lines is that newly
> > > submitted ebuilds get much broader attention. Especially recalling
> > > numerous calls for setting up the list of new ebuild submissions so that
> > > newcomers can start to actively contribute to the system, while allowing
> > > "core" people to concentrate on essential stuff.
> > >
> > > George
> >
> > George,
> > After reading the messages in this thread (particularly the last two
> > posted by you) I'd like to say that I agree with you and to add a couple of
> > thoughts of my own.
> >
> > I like the idea of having ebuilds submitted via bugs.gentoo.org being made
> > easily available to all gentoo users -- keeping one interface for
> > submission is a good idea.
> >
> > However instead of (as well as) your multiple package state levels how
> > about this (this is all just hypthesis, I don't know if it is possible, I
> > don't know enough about all the tools used):
> >
> > Multiple cvs branches along the lines of this:
> >
> > Testing Branch - primarily for use by developers.
> > - new ebuilds from bugs.gentoo.org come in here
> > - If there is no activity on an ebuild (it's bug)
> > for 14 days it get's moved to Unstable
> >
> > Unstable Branch - ebuilds that have made it out of testing and *should*
> > work for most users
> > - flagged as Stable after 28 days of nil activity on the bug
> > - need to be reviewd by gentoo dev team before getting into
> > Stable
> >
> > Stable Branch - ebuilds that have made it out of Unstable and are suitable
> > for general consupmtion.
> > - the beginning of the "next" gentoo release branch
> >
> > Release Branch - ebuilds that are the *current* release of gentoo
> > - no changes (except critical security and bug fixes) to
> > be made to this branch
> >
> > My proposal to integrate this into the portage system and give users a
> > means of selecting which branch they wish to rsync against.
> >
> > eg:
> > root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> > ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
> >
> > or
> >
> > root@gentoobox # emerge rsync
> > ... updating /usr/portage/release from cvs.gentoo.org
> >
> > ie: emerge defaults to using the release branch.
> >
> > It may mean a slightly larger /usr/portage for some users (particularly
> > devs), but I think it is needed to reduce the rash of -rX ebuilds that are
> > coming out as the developers _react_ to all the problems that are occuring.
> >
> > This will also allow new users to install a version of gentoo that will
> > actually work first go. Then as they get comfortable with the system they
> > can start to experiment, first with Stable ebuilds and then move on to
> > Unstable and become part of the development process.
> >
> > Just my $0.02, either way I'm still going to continue to use gentoo, it is
> > by far the best way to learn about and use linux going.
> >
> > --
> > Troy Dack
> > http://linuxserver.tkdack.com
> >
> > "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> > the Ugly)." (By Matt Welsh)
> >
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-28 3:22 ` Aaron Cohen
@ 2002-03-28 6:52 ` George Shapovalov
2002-03-29 13:10 ` Chris Johnson
0 siblings, 1 reply; 25+ messages in thread
From: George Shapovalov @ 2002-03-28 6:52 UTC (permalink / raw
To: gentoo-dev
Thanks!
you might be willing then to read my detailed description :-), link to which
I just posted on mailing list:
http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
George
On Wednesday 27 March 2002 19:22, you wrote:
> It sounds like a good idea!
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-28 6:52 ` George Shapovalov
@ 2002-03-29 13:10 ` Chris Johnson
2002-03-30 11:04 ` George Shapovalov
0 siblings, 1 reply; 25+ messages in thread
From: Chris Johnson @ 2002-03-29 13:10 UTC (permalink / raw
To: gentoo-dev
George and all,
I'd like to modify/simplify this proposal somewhat. George's proposal is
complementary and more comprehensive, but I try to cut it down to what I
think is the minimally sufficient system. I explain further at this
link:
Background/motivation:
http://relentless.org:8000/gentoo/
Short proposal plus forum:
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581
Enjoy, and I'm open for comments!
Chris
On Thu, 2002-03-28 at 00:52, George Shapovalov wrote:
> Thanks!
>
> you might be willing then to read my detailed description :-), link to which
> I just posted on mailing list:
> http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
>
> George
>
> On Wednesday 27 March 2002 19:22, you wrote:
> > It sounds like a good idea!
> >
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-29 13:10 ` Chris Johnson
@ 2002-03-30 11:04 ` George Shapovalov
0 siblings, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-30 11:04 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1467 bytes --]
Chris
I cannot post to the forum, all I get in responce is this:
Request Error The server has encountered an internal server error. The error
has been logged and will be investigated by our system programmers.
AOLserver/3.3.1+ad13 on http://relentless.org:8000
Therefore I attach my posting here.
PS
Don't you think we should change the topic name? I am afraid this "unstable
branch" stuff scares @gentoo.org people off :-).
If you agree please reply off my posting under "distributed ebuild
processing" or start the new thread.
George
On Friday 29 March 2002 05:10, you wrote:
> George and all,
>
> I'd like to modify/simplify this proposal somewhat. George's proposal is
> complementary and more comprehensive, but I try to cut it down to what I
> think is the minimally sufficient system. I explain further at this
> link:
>
> Background/motivation:
> http://relentless.org:8000/gentoo/
>
> Short proposal plus forum:
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=65
>81 Enjoy, and I'm open for comments!
>
> Chris
>
> On Thu, 2002-03-28 at 00:52, George Shapovalov wrote:
> > Thanks!
> >
> > you might be willing then to read my detailed description :-), link to
> > which I just posted on mailing list:
> > http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
> >
> > George
> >
> > On Wednesday 27 March 2002 19:22, you wrote:
> > > It sounds like a good idea!
[-- Attachment #2: Chris_forum-1.txt --]
[-- Type: text/plain, Size: 6604 bytes --]
Chris: Thanks for contribution!
First I would like to go over conceptual stuff. I totally agree, that unobscured ebuild flow is central to the success and scalability of the distribution. Your points on what are you looking for in the user feedback (namely reports of what worked and what did not) are very essential. This is a kind of input I was looking for.
I see now that we are attacking the problem from different sides, you jump right at what you as user would like to see and I was thinking in terms of how to introduce distributed ebuild processing with minimal effort and maximum security. I must say that I generally prefer evolution over revolution :-).
Now to the technical stuff:
I see that we think about packages in a different way. I opted for every change to any ebuild be specifically visible: every update by original author or anybody willing to contribute goes as a new -rX ebuild. These ebuilds are rated according to voting system. Effectively this is a CVS realisation, however since the needs are quite specific it has to be modified. I think that addresses your concerns to some extent - every attempt is available and successfull ones are better visible.
I created this design on a presumption (which I did not realise at the time but now see its influence) that as a successful project which finally left tight hacker community for a large world, gentoo has have three categories of users: 1.regular users 2.developers 3.core developers With a popular distribution 1st category will outnumber others (and at some point greatly) and thus provide sufficient testing. It may be essential to have silent votes submitted or it may be better to require users to take an action to submit the vote. We can never know beforehand. That's why I did not just push for a specific voting system but instead tried to quickly compile a few possibilities. I am sure in the end we will settle on initial realisation (probably something mixing both possibilities), as well as I am sure that we will have to readjust it later :-).
BTW, I am going to rewrite my chapter devoted to voting systems. Right now it is not much more than a few paragraphs of raw thoughts. I also have an idea about developer ratings to complement votes for ebuilds (and make overall voting mechanism more efficient). I will write this down sometime over this coming week.
Promotion threshold levels: I strongly feel against setting them in stone, whatever stability level structure we will end up with. It WILL have to be readjusted as a userbase will grow.
On a related note. As system grows the more decentralized it gets. However this does not happen in a big crash-event normally. Usually it goes through stages, like benevolent dictatorship -> core group in charge -> delegation of partial processing rights to outsiders -> core group as coordinating center... and for successfull project the transitions are normally pretty smooth. Therefore in my design I try to accomodate all the needs.
1. We have to provide possibility to keep resultant distribution stable. Therefore I consider my stability levels and requirement for user confirmation of ALL ebuilds essential. I will update this section in the main file (proposal.html) as well. 2. It seems that your stability levels are pretty similar to mine and even overlap somewhere:
2.1 I think tere is misconception in your text: your "Stable" ebuilds correspond not just to core in mine structure but to core and approved comined. The distinction on my side is purely functional, they both are stable, while core require more specific core developer intervention: they cannot be commited automatically, instead they go through core group.
Approved CAN be commited automatically, they are accessible, only they reach approved status upon core developer blessing. This is more related to security levels of distribution then to ebuild acessibility.
All other ebuilds do not require core groupintervention al att. Well, technically none require. If ebuild does not get core developer attention it can still reach confirmed status. With many users setting their Stability_Level = confirmed you will effectively get decentralized distribution without central control on majority of packages. No "manual certification" as you mentioned it required. Only on core packages.
2.2 However there is an additional feature you want represented more specifically, that is to see all successfull and all failed attempts. I do not want to go into voting specifisity at this point. Lets try to keep design modular from the very beginning. So, what about such scenario: All the limitations I imposed in "Server perspective chapter" will require that every modification to any ebuild shell go as a new -r(X+1) ebuild. If original ebuild fails it gets "unstable" and author or interested users are forced to repair it. And all their modifications will stay in the tree - visible. The success of implementation is visible as its aggregate vote. Unsuccessfull are visible if you opt for it (rsync_Stability_Level flag).
The best thing - this info is available locally. nd you do not need to use special tools for it - avoids unnecessary database branching.
Well, actually it may be desirable to have all this data stored remotely. It is possible to do it both ways and write tools that do both. It is possible to keep one database per LAN and sync it to some central depository. As system grows single central depository will become a single point of failure and distributed system similar to DNS or FreeNet can be used (this is already Mega level, when we surpass RedHat, Mandrake and RedFlag combined :-)). Infinite configurability is possible, and this is why I think that with proper care gentoo can become THE unifying (but not limiting) base. All it takes is to follow evolution.
Now back to evolution and design. While we have to strive to keep the system secure and choose the best implementation corresponding to presennt user base (what defines how much centralized it should be kept at the moment) we should not forget the ultimate goal: infinite scalability, evolution is a distributed process. On the other hand while we strive to reach infinite scalability we should not forget issues at hand: keep it secure sequre and appropriate. Ok, I feel like I start to sound political here, thats a sign to stop and put some time in the actual desing :-), and may be start thinking about implementation?
PS I will submit rewised proposal to bugs.gentoo.org in about a week. I think to provide links to both proposals and to this forum. What do you think?
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
2002-03-25 14:57 ` Aaron Cohen
@ 2002-03-26 3:36 ` George Shapovalov
2002-03-29 23:40 ` Chris Johnson
2 siblings, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-26 3:36 UTC (permalink / raw
To: gentoo-dev
Hi Troy
Some new activity on this thread, cool!
If I understand correctly your proposal you talk about supporting different
ebuild stabiliyt/status levels by means of creating new branches for every
stability level.
This seems semantically very similar to my proposal (including use of shell
variables). There are some technical discripances though which I would
like to address here.
I shell say that I am working now on writing a detailed proposal of multiple
ebuild stability levels (and immediate submission visibilty). I will try to
finish it and submit the link to this maillist as soon as possible.
> George,
> After reading the messages in this thread (particularly the last
> two posted by you) I'd like to say that I agree with you and to add a
> couple of thoughts of my own.
>
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made
> easily available to all gentoo users -- keeping one interface for
> submission is a good idea.
>
> However instead of (as well as) your multiple package state levels how
> about this (this is all just hypthesis, I don't know if it is possible, I
> don't know enough about all the tools used):
>
> Multiple cvs branches along the lines of this:
As I said semantically it seems very similar. Technically though, how
exactly will this be represented in user (synced) portage tree? Will user
have portage, portage-testing, portage-unstable, etc? I am afraid it will
create more confusion especially if you take into account the need to update
existing ebuilds. What about the package in the stable tree which was updated
and new ebuild should get a "testing" status? If you want to keep things
semantically consistent and secure you will end up with pieces of package in
different trees. Is this then really different from additional suffix in
ebuild name? I designed this change to ebuild name in order to be consistent
with present ebuild processing scheme. It seems that it should require less
modification to portage tools this way and it should keep the whole process
as much as possible automated, not only on the user but also on maintainer
side. I would guess that maintainers of the server will be unhappy about
having to support additional trees.
>
> Testing Branch - primarily for use by developers.
> - new ebuilds from bugs.gentoo.org come in here
> - If there is no activity on an ebuild (it's bug)
> for 14 days it get's moved to Unstable
I personally would be quite opposed to automatic promotion on my system. I
think it should require some user intervention, such as votes for
intermediate stability level and core group revision before it gets marked as
stable. This way you can get whatever stability you want for you setup.
I will post the link to all the details as soon as I'll get enough time to
finish it, I promise :-).
> eg:
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
Nice idea. I actually thought about inclusion of such flags into
/etc/make.conf (and all other related files). It should definitely be
possible to set this in command line as well.
It is good to know that people think along the same lines generally WRT this
issue.
George
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
2002-03-25 14:57 ` Aaron Cohen
2002-03-26 3:36 ` George Shapovalov
@ 2002-03-29 23:40 ` Chris Johnson
2002-03-30 6:02 ` Troy Dack
2 siblings, 1 reply; 25+ messages in thread
From: Chris Johnson @ 2002-03-29 23:40 UTC (permalink / raw
To: gentoo-dev
What I don't like about this, and catching Aaron Cohen's tone perhaps in
his follow-up email ("Great, we will be a Debian Want a be!"), is the
complexity of a set of cvs branches, stability levels, etc.
It's what has made a mess of debian from the perspective of having
mature packages float to the top and become available in a timely
manner. See, if I run debian, I have to make all sorts of decisions
about what stability level, which tree, which mirrors, etc. I want to
connect to. With the quality of ebuilds and the ease of the gentoo
system, we can have much lower complexity and higher quality.
I vote strongly against any cvs branches of the portage tree--that's why
we currently have the -rx designations, anyway! Leverage that and the
organic nature of the community (i.e., see my proposal at
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581 )
to get a simple, effective system.
Please, avoid the duplication of effort that all the branches of debian
represent!
Chris
On Mon, 2002-03-25 at 05:23, Troy Dack wrote:
> ( new post @ bottom, original left in for continuity ... )
>
> On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:
>
> > Hi All.
> >
> > I just looked again through the recent thread and here are some thoughts I
<snip>
> > newcomers can start to actively contribute to the system, while allowing
> > "core" people to concentrate on essential stuff.
> >
> > George
>
> George,
> After reading the messages in this thread (particularly the last two
> posted by you) I'd like to say that I agree with you and to add a couple of
> thoughts of my own.
>
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made
> easily available to all gentoo users -- keeping one interface for
> submission is a good idea.
>
> However instead of (as well as) your multiple package state levels how
> about this (this is all just hypthesis, I don't know if it is possible, I
> don't know enough about all the tools used):
>
> Multiple cvs branches along the lines of this:
>
> Testing Branch - primarily for use by developers.
> - new ebuilds from bugs.gentoo.org come in here
> - If there is no activity on an ebuild (it's bug)
> for 14 days it get's moved to Unstable
>
> Unstable Branch - ebuilds that have made it out of testing and *should*
> work for most users
> - flagged as Stable after 28 days of nil activity on the bug
> - need to be reviewd by gentoo dev team before getting into
> Stable
>
> Stable Branch - ebuilds that have made it out of Unstable and are suitable
> for general consupmtion.
> - the beginning of the "next" gentoo release branch
>
> Release Branch - ebuilds that are the *current* release of gentoo
> - no changes (except critical security and bug fixes) to
> be made to this branch
>
> My proposal to integrate this into the portage system and give users a
> means of selecting which branch they wish to rsync against.
>
> eg:
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
>
> or
>
> root@gentoobox # emerge rsync
> ... updating /usr/portage/release from cvs.gentoo.org
>
> ie: emerge defaults to using the release branch.
>
> It may mean a slightly larger /usr/portage for some users (particularly
> devs), but I think it is needed to reduce the rash of -rX ebuilds that are
> coming out as the developers _react_ to all the problems that are occuring.
>
> This will also allow new users to install a version of gentoo that will
> actually work first go. Then as they get comfortable with the system they
> can start to experiment, first with Stable ebuilds and then move on to
> Unstable and become part of the development process.
>
> Just my $0.02, either way I'm still going to continue to use gentoo, it is
> by far the best way to learn about and use linux going.
>
> --
> Troy Dack
> http://linuxserver.tkdack.com
>
> "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> the Ugly)." (By Matt Welsh)
>
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-29 23:40 ` Chris Johnson
@ 2002-03-30 6:02 ` Troy Dack
2002-03-30 8:57 ` George Shapovalov
2002-03-30 9:03 ` Chris Johnson
0 siblings, 2 replies; 25+ messages in thread
From: Troy Dack @ 2002-03-30 6:02 UTC (permalink / raw
To: gentoo-dev
On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together
and come up with:
> What I don't like about this, and catching Aaron Cohen's tone perhaps in
> his follow-up email ("Great, we will be a Debian Want a be!"), is the
> complexity of a set of cvs branches, stability levels, etc.
>
> It's what has made a mess of debian from the perspective of having
> mature packages float to the top and become available in a timely
> manner. See, if I run debian, I have to make all sorts of decisions
> about what stability level, which tree, which mirrors, etc. I want to
> connect to. With the quality of ebuilds and the ease of the gentoo
> system, we can have much lower complexity and higher quality.
>
> I vote strongly against any cvs branches of the portage tree--that's why
> we currently have the -rx designations, anyway! Leverage that and the
> organic nature of the community (i.e., see my proposal at
>
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581
> ) to get a simple, effective system.
>
> Please, avoid the duplication of effort that all the branches of debian
> represent!
>
> Chris
Fair enough... I realise that the -rx designations are there, however I
have had -rx .ebuilds fail on numerous occassions because there was simply
not enough testing before the ebuild was submitted to CVS.
This is fine if you already have a package installed ... simply file a bug,
or slap the ebuild maintainer on IRC and in a few hours (a day or two at
most) the ebuild is fixed and away you go.
The problem comes when a new user is trying to build their system and they
get all these errors. We don't want to discourage newcomers by having a
tree of ebuilds that is not 100% stable for their first installation.
That was my main reason for suggesting seperate CVS branch(es).
I agree that Gentoo is not targeted at the "I've never seen linux before
and thought I'd give it a go" type of user (that's what RH & MDK do), but I
don't think we should make new users jump through too many hoops simply
because an ebuild maintainer has hastily submitted an ebuild --
particularly for core packages (baselayout is one that comes to mind).
Perhaps a comprimise ....
A stable/install CVS branch that is only used during the initial
bootstrap/build process and afterwards portage defaults to using the
regular CVS tree?
Still it is a refreshing way to get my linux "fix"!
--
Troy Dack
http://linuxserver.tkdack.com
The onset and the waning of love make themselves felt in the uneasiness
experienced at being alone together.
-- Jean de la Bruyere
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-30 6:02 ` Troy Dack
@ 2002-03-30 8:57 ` George Shapovalov
2002-03-30 9:03 ` Chris Johnson
1 sibling, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-30 8:57 UTC (permalink / raw
To: gentoo-dev
Please see below.
On Friday 29 March 2002 22:02, you wrote:
> On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together
> > I vote strongly against any cvs branches of the portage tree--that's why
> > we currently have the -rx designations, anyway! Leverage that and the
> > organic nature of the community (i.e., see my proposal at
>
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=65
>81
>
> > ) to get a simple, effective system.
> >
> > Please, avoid the duplication of effort that all the branches of debian
> > represent!
> >
> > Chris
>
[snip]
> The problem comes when a new user is trying to build their system and they
> get all these errors. We don't want to discourage newcomers by having a
> tree of ebuilds that is not 100% stable for their first installation.
>
> That was my main reason for suggesting seperate CVS branch(es).
[snip]
> Perhaps a compromise ....
>
> A stable/install CVS branch that is only used during the initial
> bootstrap/build process and afterwards portage defaults to using the
> regular CVS tree?
With multiple stability levels you will get the same effect by setting
Stability_Level = approved
rsync_Stability_Level = Stability_Level
and withoud a need for a separate CVS branch!
New users will get a stable system and when later they learn enough about
linux and gentoo in particular they will know what these flags mean and will
start exploring ... :-).
(here I refer to the flags I introduced in my writeup at:
www.its.caltech.edu/~georges/gentoo/epsp/proposal.html )
Chris proposed somewhat different definition of stability levels. While
overall structure is different the "stable" ebuilds will correspond to just
such level. (please visit:
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581
for his submissions where he brings up some important aspects. Chris: I am
going to reply in the forum soon).
Side note:
I am not sure if we should use forum which Chis set up or continue in the
list. First allows nice concise place for discussion, second gives better
exposure. In fact there is an alternative - we can use bugs.gentoo.org and I
am going to enter this proposal there (not only my writeup but whatever will
accumulate by then) either when 1.0 comes out (and freeze is over) or in
about a week or two, whichever is shorter. However this has the same problem
of low exposure, on the other hand it grabs attention of core group, so right
now I like that the best.
If only there was a discussion area setup under gentoo.org (which would not
require a bugzilla account. I have no problem with that but it scares off
many people. For the "discussion" situation it is not really necessary
anyway).
George
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [gentoo-dev] Re: Unstable branch proposal - second round
2002-03-30 6:02 ` Troy Dack
2002-03-30 8:57 ` George Shapovalov
@ 2002-03-30 9:03 ` Chris Johnson
1 sibling, 0 replies; 25+ messages in thread
From: Chris Johnson @ 2002-03-30 9:03 UTC (permalink / raw
To: gentoo-dev
<special note to new readers>
I wonder if anyone else on this list cares to give input. (Hint:
maintainers who really know what this is all about, drobbins, etc.).
</special note>
On Sat, 2002-03-30 at 00:02, Troy Dack wrote:
> On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together
> and come up with:
>
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581
<snip>
> Fair enough... I realise that the -rx designations are there, however I
> have had -rx .ebuilds fail on numerous occassions because there was simply
> not enough testing before the ebuild was submitted to CVS.
>
> This is fine if you already have a package installed ... simply file a bug,
> or slap the ebuild maintainer on IRC and in a few hours (a day or two at
> most) the ebuild is fixed and away you go.
>
See, this whole "waiting on the maintainer" bit is what my proposal
avoids. In general, the idea is whenever *someone* gets it to work
right, their ebuild rises up into cvs to be tested by anyone running in
"10 stable installs or less" mode, which will be a sizeable portion of
the group. (My already stated threshold is in this category, e.g. if I
saw a single successful install of OpenOffice, I'd try it!--already
have, unsuccessfully.)
> The problem comes when a new user is trying to build their system and they
> get all these errors. We don't want to discourage newcomers by having a
> tree of ebuilds that is not 100% stable for their first installation.
In this case, the default will be to install in "more than {50|choose a
big number} successful installs" mode, i.e. very tested versions of each
package. Then, in the "Desktop guide" or other documents, it can be made
clear how to get the *latest* builds by changing one's make.conf to set
the "{10|20|50} successful installs or less" mode.
> That was my main reason for suggesting seperate CVS branch(es).
I'm trying to avoid branching, because that ultimately brings duplicated
effort and communication problems, not to mention contributes to the
slowness already alluded to (i.e "slap the maintainer on IRC to fix"
becomes "slap the maintainer on IRC to test it and bump it to
'stable'").
On George's scale of terms, I'm arguing for an _active system, passive
users_ as much as possible. I don't enjoy spending my whole day
bothering 50 maintainers to fix their packages, esp. when it's *easier*
to fix them myself. It's just that I'm frustrated when I make a fix--and
it goes nowhere, helps no one, and then I have to slog through web pages
to submit a bug that gets looked at a week later... yawn.
> I agree that Gentoo is not targeted at the "I've never seen linux before
> and thought I'd give it a go" type of user (that's what RH & MDK do), but I
> don't think we should make new users jump through too many hoops simply
> because an ebuild maintainer has hastily submitted an ebuild --
> particularly for core packages (baselayout is one that comes to mind).
Agreed. Baselayout/bootstrap + core systems are "maintained"; the rest
are "free float". Besides, if what I'm saying could be implemented,
then ebuilds with high success rates tend to stick in cvs, and ones that
are not successful in the field get demoted and replaced. Automatically.
> Perhaps a comprimise ....
>
> A stable/install CVS branch that is only used during the initial
> bootstrap/build process and afterwards portage defaults to using the
> regular CVS tree?
Why a need for seperate trees: only allow the "freefloat" system to
affect non-core packages, and when doing an install only use packages
that have ratings of "100 successful installs or greater|'STABLE'
blessing". This seems to solve the problem.
> Still it is a refreshing way to get my linux "fix"!
>
> --
> Troy Dack
> http://linuxserver.tkdack.com
>
Me too! Thanks for your response and participation! How can we measure
if this conversation will be fruitfull?
Chris
^ permalink raw reply [flat|nested] 25+ messages in thread