public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Chris Johnson <cmjohn@mail.utexas.edu>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] Re: Unstable branch proposal - second round
Date: 29 Mar 2002 17:40:37 -0600	[thread overview]
Message-ID: <1017445237.10692.31.camel@mule.relentless.org> (raw)
In-Reply-To: <20020325112402.296491A429@linuxbox.internal.lan>

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)
> 




  parent reply	other threads:[~2002-03-29 23:40 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
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 [this message]
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=1017445237.10692.31.camel@mule.relentless.org \
    --to=cmjohn@mail.utexas.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