Re: An old idea, brought back to life
On Mon, Dec 21, 1998 at 03:15:49PM -0500, Buddha Buck wrote:
> Mr. Levi,
How formal. %^)
> I don't know if you have read the documentation that was developed
> when this idea was first brought up several months ago. From what you
> say, it is apparant that you have a different interpretation of the
> idea than I do.
>
> It was my understanding that the following "distributions" would be
> available:
>
> unstable
> -- packages in unstable had passed very basic tests -- was packaged
> technically correctly by a known maintainer. It would not mean that
> the package was bug-free, or even consistant in terms of dependencies.
>
> prerelease
> -- packages in prerelease would be "consistant", in that all
> dependencies would be able to be met by packages in prerelease only.
> There may be stronger automated requirements, but again, "bug-free"
> isn't a requirement.
>
> stable
> -- packages in stable would be "consistant" and "release-critical
> bug-free". Stable is supposed to be always ready for release, and
> should be as bug-free as we can make it.
>
> Periodically, a snapshot of stable is made and released.
>
> Packages would move from Incoming to unstable based on the same sort of
> tests we use now to move packages from Incoming to unstable.
Are you sure this is what you mean? (I'll follow-up at the end.)
> Packages
> would move from unstable to prerelease based on their dependency
> information -- if foo depends on bar, and bar isn't in prerelease, foo
> will be held in unstable. This process can be automated.
>
> Packages would move from prerelease to stable based on two criteria:
> time -- they must be in prerelease for a certain amount of time so that
> the package can get testing (like unstable now, there will likely be a
> large number of people who would follow prerelease), and bugs -- there
> must be no critical bugs.
>
> Provisions will be made for downgrading. For instance, (assume
> versioned depends in this example) if foo-8 is in stable, and bar-8 and
> foo-9 are in prerelease, bar depending on foo, all is fine. bar-8's
> dependency on foo-8 is met by foo-8 in stable. However, if a
> release-critical bug is found in foo-8, it must be pulled from stable,
> and replaced with the previous version in stable, foo-7. Now bar-8
> doesn't have it's dependency met, so it must be pulled, and replaced
> with its previous version (bar-7).
>
> These problems are known, and the proposal was designed to allow them.
>
> I would expect that most of the people currently tracking unstable
> would start tracking pre-release (occasionally taking the odd package
> or two from unstable, if necessary), and that some of the people
> currently "tracking" stable would start tracking the new stable. Many
> would still upgrade only on release, but that would be OK.
>
> Is this what you envisioned the proposal would be like?
It sounds similar. I don't think that changing the names is the most
important facet of the proposal. Let me clarify that I think there
are two problems:
1) Just before release, it takes a long time for package updates to
make their way into the mirrored archives so that we can test
them. This is due to the appropriate caution of the release
manager(s).
2) Performing incremental updates to a running system is desirable
for the sake of testing. Packages will be upgraded and
downgraded in order to isolate problems or return a broken system
to a working state.
The first problem is addressed by speeding the transition from
Incoming to a mirrored portion of the archive. This should be simple
to automate given that we have signatures and can assume that a signed
package from a Debian developer is valid...but untested.
The second problem is due to the fact that we cannot presently install
systems that are partially in one distribution and another. For
example, we cannot easily mix potato and slink when there are
conflicting library updates. This is OK, but it inhibits testing.
If we make prerelease without changing the way that apt/dselect works,
we haven't really solved the interesting problem improving
testability.
I recognize and appreciate the desire to improve the dependency
consistency of our distributions. This is desirable. This is what I
see is addressed by the proposal which appears to be focused on
improving the archive.
I don't see an improvement in our ability to incrementally install
part of, for example, prerelease to a system already running stable.
If I want to test a new init-2 that requires library inithelper-2 in
prerelease and the -1 versions are in stable, we have sufficient
information to allow the user to upgrade, test, and downgrade if there
is trouble. Whether we call these unstable/stable,
prerelease/stable, unstable/frozen does not IMHO solve the above
problems.
So, it doesn't matter to me what we call them. And, I think that the
things proposed are fine, but because changing the archive is
expensive I believe that the proposal as it stands has 'fingers and
toes' but not 'hands and feet'.
Cheers.
Reply to: