From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from MUSE.clarku.edu (muse.clarku.edu [140.232.153.245]) by chiba.3jane.net (Postfix) with ESMTP id C9BD82019AAB for ; Wed, 27 Mar 2002 21:27:37 -0600 (CST) Received: from jabberwokk.abac.com (216-55-133-42.dsl.san-diego.abac.net [216.55.133.42]) by MUSE.clarku.edu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id H34FJNK1; Wed, 27 Mar 2002 22:23:12 -0500 Subject: Re: [gentoo-dev] Re: Unstable branch proposal - second round From: Aaron Cohen To: gentoo-dev@gentoo.org In-Reply-To: <1017068283.2156.5.camel@jabberwokk.abac.com> References: <200203161942.LAA07376@chamber.cco.caltech.edu> <20020325112402.296491A429@linuxbox.internal.lan> <1017068283.2156.5.camel@jabberwokk.abac.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2- Date: 27 Mar 2002 22:22:55 -0500 Message-Id: <1017285786.2332.6.camel@jabberwokk.abac.com> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: b098b9f6-54d9-4740-ae23-e9dc33d6828a X-Archives-Hash: b27c70007deed9e877207770df270693 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