public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mike Payson <mike@bucky.dawgdayz.com>
To: gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] making %95 of users happy
Date: Fri, 19 Apr 2002 04:34:40 -0700	[thread overview]
Message-ID: <200204190434.40788.mike@bucky.dawgdayz.com> (raw)
In-Reply-To: <20020419101913.GB11203@shellak.helsinki.fi>

On Friday 19 April 2002 03:19 am, Einar Karttunen wrote:
> On 19.04 11:44, Terje Kvernes wrote:
> >   the only problem I see with using a profile is that it'll "lock" you
> >   down more than you'd like.  it would be nice to say "give me a
> >   stable core, but a bleeding edge movieplayer and games".
>
> Which is where branches like in debian help you. There are some problems
> however. A big one is dependencies e.g. packages A and B use package C,
> and need a specific version. A and B of stable use C version 1.2 and
> the ones in devel 2.0. Now you want to use the devel version of A on
> your stable system and have to use the devel versions of A, B and C.
> Replace C with e.g. gtk and you see the problem.

Here's my suggestion posted previouly to the Gentoo-user list. I think this 
solution prevents the problems associated with branches, while not locking 
anyone into a system that they're not happy with.

I propose the addition of stability levels to gentoo. This would allow users 
to run a bit behind the state-of-the-art, while still taking advantage of the 
features Portage provides.

The levels I propose would be something like:
Stable: Conservative, for people who require extreme stability.
Standard: The base level. A few weeks behind what we have today.
Current: Gentoo as we know it today. For people who are a bit more 
     adventurous, but aren't willing to accept betas.
Devel: beta packages are installed by default. Only for the most adventurous.

In addition, all packages at a fixed version level (ie 1.0) would be flagged 
as such, allowing a user to recreate that version number months down the 
road.

This doesn't lock people in to a given stability level, it only changes the 
default behavior of the installer & emerge. The stability level could always 
be overridden, just by specifying a newer (or older) version of a particular 
package.

These features should be easy to implement on top of the current package mask 
system (though I should state: I am not a programmer, and am not very 
familiar with the internal workings of Portage). 

This should not be viewed as creating 'branches'. Instead, it creates 
'reference points'. All development takes place at the devel level. From 
there, the only maintenance required would be gradually changing the masks to 
move packages in to the progressively more stable environments. This will 
require some extra work on behalf of the package maintainers, but it 
shouldn't require more then maybe 30 minutes of work a month on actively 
developed packages (even less on the vast majority of packages).

A more flexible package management system simplifies things greatly. Many 
users don't want a bleeding edge system. How often are significant bugs 
discovered only after a upgrade has been available for weeks? And in the 
three months or so I've been using Gentoo, I've already seen at least a 
couple of times when packages were accidentally unmasked prematurely.

Having stability levels allow the adventurous to run a bleeding edge system, 
the middle 80% can run a system that is maybe a few weeks behind the bleeding 
edge. And those people who need a bit more stability can run stable. 

Gentoo's ease of management makes it ideal in many ways for an office 
environment and servers, but when you have users relying on the computers 
working every morning when they get there, bleeding edge doesn't cut it. 
Having a stable flag makes this sort of system manageable. 






  reply	other threads:[~2002-04-19 11:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-18 12:25 [gentoo-dev] making %95 of users happy Gaarde
2002-04-18 18:29 ` Todd Wright
2002-04-18 19:28   ` Stefan Boresch
2002-04-19  3:25     ` Fuper
2002-04-19 12:04       ` Todd Wright
2002-04-18 22:09         ` Sherman Boyd
2002-04-19 14:15         ` Fuper
2002-04-18 19:35   ` Terje Kvernes
2002-04-19  8:42     ` Paul de Vrieze
2002-04-19  9:44       ` Terje Kvernes
2002-04-19 10:19         ` Einar Karttunen
2002-04-19 11:34           ` Mike Payson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-19 17:57 Gaarde
2002-04-20  0:30 ` John White
2002-04-20 18:26 Gaarde

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=200204190434.40788.mike@bucky.dawgdayz.com \
    --to=mike@bucky.dawgdayz.com \
    --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