Grades of stable-ness [was: GNOME --> potato: let's do it!]
On Fri, Apr 30, 1999 at 07:00:09PM -0500, Ossama Othman wrote:
> Hi,
>
> On 1 May, Pedro Guerreiro wrote:
> > Do you guys remember that you are copying to potato, not slink? (or did I miss
> > something?) This means IMO that you CAN do uploads later.
>
> > I think this whole stage area is a great think, but this time went way out of
> > line (and time :) ). The purpose of the staging area was not to build a rock
> > stable release of GNOME (not the potato anyway), but to bring everything
> > (mainly libraries) up-to-date. I think the potato upload/copying should have
> > been done a long time ago (the unstable area is called unstable for some
> > reason).
>
> I can understand what you are saying. However, I disagree. I am very
> glad that we have all come together and coordinated our efforts. GNOME
> in potato was horrible before we got together. I consider
> debian-gtk-gnome more than a tool to get things up to date with each
> other. I consider it an opportunity to get things working properly, or
> as well as possible, without having to upload new libraries/releases to
> the main archive every week.
>
> Just because potato is unstable doesn't mean that we should just upload
> things to it whenever something new comes along. I consider unstable
> the "stable bleeding edge" distribution. Of course, things are going
> to break but IMO we should make strong efforts to try to ensure that
> things don't break, even though the distribution is considered
> unstable. The stable distribution gets too old too fast, which is
> probably why most of us like to run the unstable distribution.
Hmm... Sounds like a job for... POLICY MANUAL! (Hmm, odd, policy-manual
isn't packaged.) ... Time Passes ... Ahh, from the developer's-reference:
5.6.1: "Active development is done in the unstable distribution" ... " [T]he
contents of this distribution change from day-to-day. Since no special
effort is done to test this distribution, it is sometimes ``unstable.''
I take this to mean that _active_, this-will-cause-breakage development
should be in unstable. In My Very Humble Opinion, staging areas are somewhat
cathedralish. (And I'm very bizarre, as anyone who knows me will tell you.)
> Note that I'm not trying to be adversarial. I'm just expressing my
> opinions. Nothing personal Pedro. :-)
Ditto, along with disclaimer: just-a-user,-not-(yet)-a-developer. I actually
do have a constructive point to this.
In any case, we all agree that the need for the staging area (whatever it
is) is past.
(The following is the reason for possibly excessive quoting and cc/reply-to
debian-policy. Sombody remind me again why I can't point to an archive of
debian-gtk-gnome?)
Might I raise the suggestion that the fact that there is an issue of staging
areas at all means that we need to move to a three-level system:
a. unstable -- Breakage Will Occur. Don't run unless you are prepared to
restore from backup and possibly have your computer catch fire and/or have
your monitor explode. Hard hat required by OSHA regulations.
b. semi-stable -- We think it will work, but we make no guarantees (yes,
Virginia, even less then normal with the GPL-et-all). Should be at least
as solid as good crusty bread. Might well contain annoying, but not
dangerous, bugs.
c. stable -- we belive this to be as solid as granite. (And being in DC
today, you'd be amazed how well the stuff holds up to 175 (or so) years
of wear-and-tear.)
A new upload could start in unstable, then work it's way down to semi-stable
and finally stable after a period in each stage where there are no bugs of
worse then a given severity.
What do you people think, especialy those who remember why the current
system exists as it does? I generaly think that the current system has the
same problem that the 2.0->2.1->2.2 (kernel) devel cycle does: people expect
some degree of stableness in unstable, so you have to be very careful making
this-will-break updates, leading to pre-releases (kernel) or staging areas
(debian), both of which are poor work-arounds, seeing as the infrastructure
is conspiculsouly absent (auto-builders, linux-kernel-announce,
bugs.debian.org, etc.)
Note that this means that there would be a natural, slow, replacement of
packages in a distribution, not the current stable is hamm, now it's slink,
and shortly it will be potato movement. I'm not certian what to do about
big conflicts/replaces things like libc2.1. Perhaps a simple rule that no
package can depend or require on a package of lesser stability? This
obviously needs to be discused more. (For one thing, that dosn't handle
conflicts-but-does-not-replace -- but I'm not certian that that is
supportable.)
Again, disclamer: I don't really know what I'm talking about.
Not-a-developer, and fairly-new-to-debian.
-=- James Mastros
--
"My friend Data: You see the world with the wonder of a child, and that
makes you more human then any of us."
-=- Lt. Tasha Yar, upon the occasion of her death.
cat /dev/urandom|james --insane=yes > http://www.rtweb.net/theorb/
ICQ: 1293899 AIM: theorbtwo YPager: theorbtwo
Reply to: