From: Aaron Cohen <acohen@clarku.edu>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Re: Unstable branch proposal - second round
Date: 27 Mar 2002 22:22:55 -0500 [thread overview]
Message-ID: <1017285786.2332.6.camel@jabberwokk.abac.com> (raw)
In-Reply-To: <1017068283.2156.5.camel@jabberwokk.abac.com>
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
next prev parent reply other threads:[~2002-03-28 3:27 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-16 19:46 [gentoo-dev] Unstable branch proposal - second round George Shapovalov
2002-03-16 20:59 ` George Shapovalov
2002-03-17 0:52 ` [gentoo-dev] multiple pkg state levels, was: Unstable branch proposal George Shapovalov
2002-04-16 21:29 ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
2002-03-16 22:09 ` Brent Cook
2002-03-17 0:26 ` Daniel Mettler
2002-04-17 0:33 ` Michael Lang
2002-03-17 1:13 ` George Shapovalov
2002-03-17 19:53 ` [gentoo-dev] separate catalog for my ebuilds Giulio Eulisse
2002-03-17 21:40 ` Chad M. Huneycutt
2002-04-16 22:08 ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
2002-03-17 1:04 ` George Shapovalov
2002-03-19 13:05 ` [gentoo-dev] Usb mouse issues with 2.4.17-r5 Michael M Nazaroff
2002-03-20 8:11 ` Stefan Jones
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 [this message]
2002-03-28 6:52 ` George Shapovalov
2002-03-29 13:10 ` Chris Johnson
2002-03-30 11:04 ` George Shapovalov
2002-03-26 3:36 ` George Shapovalov
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1017285786.2332.6.camel@jabberwokk.abac.com \
--to=acohen@clarku.edu \
--cc=gentoo-dev@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox