Re: Implementing "testing" (was: Re: Potato now stable)
On Fri, Aug 18, 2000 at 09:26:34PM +1000, Anthony Towns wrote:
>
> Another reason to run unstable is to live on the actual bleeding edge:
> testing will always be around two weeks out of date. That can be a fair
> while, if you're impatient.
>
> Supporting this, there's some Apt changes in CVS that'll let people choose
> a few packages from one distribution and leave the rest from another. Two
> possibilities come to mind: either running "testing" most of the time,
> but using a bunch of programs from "unstable" because you're interested
> in their development; or running mostly from "unstable" except for a few
> packages you can't afford to have break on that machine. Either way you
> have a slightly larger buffer between an upload and it making it into
> "testing".
This seems to me to be important.
Debian developers typically have to use unstable, or some of it, if
they want to compile packages for unstable. This would allow us to
pick-and-choose. For example, I maintain a couple of GTK packages and
a GNOME package. I could use 'testing' mostly, but I could install
'unstable' versions of libgtk-dev, libgnome-dev. Then I can recompile
balsa as necessary when new versions come out, and this might go some
way towards eliminating the massive brokenness which strikes unstable
when a new incompatible library version comes out (remember the
libgtk1.1.17 era?). At least testing would be (almost) guaranteed a
consistent set of packages.
Also it's considerations like this which prompted me to start the
'gnome-staging' project when we had that big gnome upgrade.
>
> *shrug* If it turns out to be a problem, I think it'll end up being mostly
> self correcting. And even if it's not, we're still in a better situation
> than we are now because some bugs *definitely* won't make it into testing.
Yes, you're right. Your suggestions certainly can't make anything
worse than it is ;-) And they will probably make things better. I'm
not convinced they're going to be the silver bullet for speeding our
releases, but practical experience suggests that theoretical
ponderings about the release process are almost pointless ;-)
Jules
Reply to: