[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Slink to Potato

> Well, it's a bit better than that - particularly if you keep up with the
> various lists (mostly -user and -devel) you should be all right.  It's
> more a case of "pay attention and be prepared to fix things if they
> break" than anything else.  I'd guess that a fair proportion of
> developers are running at least some unstable, and we like our machines
> to continue to work.

Wouldn't it be nice is this information was collated at one location so
that people could build on what's already been done and not have to try
everything new every time.  That's what open source is about--sharing.

What I am proposing is to help collate the information, do the research
so that people coming after me don't have to "keep up with the various
lists".   This is a no-brainer.  It needs to be done and it needs to be
done now.

> > Some people just don't have the luxury of working with Unstable. However,=
>  much
> > of the software released, like Gnome, GIMP, LyX and such *is* stable.
> Sure, but which software and how does it play together :-) .  I can
> actually imagine this being a more serious problem these days with
> things like GNOME having so many librarie to get right.

Those are a nightmare.  That's why it's important for somebody who's already 
got things working with Slink to document it and share with others so that
everybody doesn't have to reinvent the wheel.

> > So what I'd like to see is
> > collection of upgrades to the current Stable from the Unstable chain, jus=
> t the
> > way its done in the Linux kernel. This will keep everybody happy and will=
>  delay
> > the obsolescense of Stable. Right now, I wouldn't recommend Slink to anyb=
> ody.
> > It's just too out of date.  I'm only playing around with it because I have
> > a need for it in the future.
> I think that's a bit extreme - this machine is running a vanilla Slink
> system plus kernel 2.2 and the GNOME panel (and it's not as though I
> couldn't do without the GNOME panel) and it does everything I would want
> in a Unix system.  There isn't much visible difference between it and
> the potato systems I run.

What's extreme is that hundreds of Debian users have stable upgraded systems
and nobody has bothered to document it and post a How-To.

And yes, I could go without GIMP and Enlightenment and even X Windows, too.
What your telling me is that when using Debian, I have to get used to using
out of date stuff.  I won't buy that when the solution is so easy--document
what you've done and put it up on a damn Web site so others can benefit
from your experience.

> Then again, the potato boxes are pretty much solid - my router/server
> box here at home runs unstable updated every weekend, and I can't recall=20
> any reboots other than for kernel upgrades or when it's been powered down=
> =20
> while I've out of town for more than a day or two.  The machine which
> currently acts as smarthost for tardis' outbound mail is running
> unstable updated approximately daily and hasn't done anything
> particularly nasty to me.

> If you really want to run an up-to-date system and can't tolerate any
> breakage at all then you probably want to have a test box sitting by
> which you can try out the new versions on before your production system
> falls over.

I have one system for this very purpose.  I will use it as a test base
before updating my S.u.S.E. machines to Debian.  My server will remain
S.u.S.E. until potato is Stable--hopefully before the end of the year.

> Otherwise, giving it a day or two before installing new packages and=20
> paying attention to bug reports and the lists should help you steer
> clear of anything really serious.  Using apt, you can track just the
> list of packages you need rather than the entire distribution.
> > What can we do to get this accomplished?
> > I'm willing to put in some work to get this ball going.  Does anybody
> > else see this as worthwhile?
> Check out the extensive existing discussion in the -devel archives.  There=
> are several proposals, some of which would require code to be written.
> IMHO it's probably enough to get the release cycle down to six months,
> though a semi-stable distribution may be one way to achieve that.

I will do that.  I will also see what kind of interest there is on this.

I, too, was thinking that this would result in what may be called a
semi-stable distribution.  Basically it means having another chain of
programs with updated contributions which include instructions on integration
with Slink.  Dependencies would have to be worked out to build .deb packages,
but that will work itself out in testing, which can be a simple go/no-go.

I welcome other ideas on this.  Please chime in.


Reply to: