Re: An old idea, brought back to life
On Fri, Dec 18, 1998 at 03:15:44PM +1000, Anthony Towns wrote:
> On Thu, Dec 17, 1998 at 09:42:43AM -0800, Oscar Levi wrote:
> > On Thu, Dec 17, 1998 at 12:18:25PM -0500, Peter S Galbraith wrote:
> > > > The idea was that unstable is always unstable. As packages became stable
> > > > they would be moved to a release distribution which is always kept (or at
> > > > least there is a reasonable attempt to keep it) as stable and as close to
> > > > release as possible.
> > > How does it handle changes that affect all packages (likelibc5->libc6) ?
>
> It relies on us coping with a mixture of packages, and not needing
> to upgrade them all at once -- so a libc6.deb is first moved across,
> followed by packages that depend on it as they become available. It's
> still Brian's decision when we've got enough libc6 packages done to
> say "Yup, that's good enough. Let's release."
And who is going to test this version? Let's say we do this. Let's
say that the unstable is the first stop for new packages. After some
time when 'we' decide that these work we put them into unstable. Who
is going to run prerelease Debian? If I run prerelease Debian, how is
that different from running the current unstable?
Now, this plan *does* make sense if we impose a testing framework on
top of prerelease. However, if we have a testing framework, there is
no reason to split unstable. We test packages before including them
in unstable and voila! we have new confidence in unstable.
If prerelease is merely a holding place where no one runs those
packages, then we can leave them in Incoming. AFAICT,
unstable/stable/frozen are intended to be archives from which we
install. Using a new one as a holding pen for untested packages seems
inappropriate.
>
> > Even without the libc5->libc6 migration, I don't think the proposal
> > has hands and feet. If we model each release as a 'product', then the
> > idea of migrating stable packages produces two debug phases. First in
> > the unstable and then in the stable. Just because a package works
> > among other unstable ones doesn't mean it will work in the stable
> > environment.
>
> This is a mischaracterisation of how unstable is intended to work.
>
> Since we would have three distributions: stable, prerelease and unstable,
> there isn't any longer a need to have every single package in unstable --
> the ones that are in operational condition go in prerelease.
Right. How do we determine if a package is operational?
> Following unstable thus means following prerelease with a bunch of upgrades
> from unstable. Packages only remain in unstable long enough to ensure there
> aren't any stupid "make-your-system-unusable" bugs.
OK. And why aren't maintainers doing this before they upload to master?
Reply to: