Re: An old idea, brought back to life
On Sat, Dec 19, 1998 at 05:57:02PM -0800, Joseph Carter wrote:
> What if a package is uploaded to frozen now that breaks something? Same
> problem, only that packages have at least a LITTLE time to be tested in
> unstable. Also, people running the pre-release version would have the
> opportunity as they do now to download and install select packages from
> unstable. In fact, if we moved this direction apt could aid in this by
> allowing greater flexability in installing select packages from unstable.
There is another way.
> The way we figure it, there are 3 kinds of users:
>
> * Those who need stability. They can't afford to have problems that come
> with development and need the system as stable as possible from the
> start and need it to remain stable. Under both the current and new
> models, they would run stable. Their only download if they install
> from CD-ROM will be pretty much what proposed-updates is, security
> fixes and dangerous bugs found after release. In apt you would have
> just stable.
>
> * Those who can afford some bugs that come with development. They want
> the features ant toys of the newest software, but they can't really
> afford to have something break. Most non-developers and even a fair
> number of developers are in this group. I expect a good number of
> developers will be running this to develop on all the time and adding
> things from unstable as they need to. This will help do what Ben
> Collins wanted and keep people focused on the release more. These type
> probably run stable with files downloaded out of unstable until
> unstable freezes. Then they all upgrade simultaneously from stable to
> frozen causing havoc to the ftp sites when we first freeze. Under the
> new system, they would download incrementally as they do after they
> have moved to frozen. Or every few months we could release a set of
> snapshot images which those who have poor bandwidth or high cost of
> using the bandwidth can purchase. In apt you would have stable and
> pre-release with possibly a future apt knowing about unstable, but not
> upgrading to unstable's packages automatically.
>
> * People who want the bleeding edge. This bunch is not timid. They
> probably laugh at those running 2.0.x kernels and call them sissies.
> They want the latest and they'll get it one way or another. They
> aren't afraid to fix something when it breaks. These people were
> likely testing Branden's new X packages from -2 or -3 and have probably
> reported countless bugs about them since. Probably they use unstable
> now, maybe even experimental and download most everything. They will
> be totally unaffected.
Your taxonomy is clear.
> I don't see how we can test any better than we do now.
That, then, is a problem.
I feel that the most essential test mode is installability. Until we
eliminate the interactivity from Debian install, we'll never nip this
one. I know there are ideas going about on this topic. We need a
method for programmed installs such that we can verify the archive for
a set of default configurations. Once there, we can do heaps of other
things.
> > I agree that the present situation has some glitches. I don't agree
> > that adding another archive branch makes sense.
>
> Not adding a branch, changing how we use the ones we have. pre-release
> is essentially a perpetual frozen which packages are moved in to a few at
> a time. When we're ready to release it we freeze it and it's out the
> door in a short time, after which packages waiting to go into pre-release
> will be moved there and the cycle starts again from the top.
So, it comes down to how do we hold packages. Perhaps is makes sense
to make only a slight adjustment to the present setup. I see a couple
of parts:
1) The move from Incoming to unstable-untested or stable-untested is
done automatically and done quickly. For the time being,
these are new archive branches.
2) As new branches, these are mirrored and available within a day of
upload.
3) The packaging system adds a hook such that the user can choose,
by package, to use the untested version or the mainline one.
4) The archive maintainers move packages from untested into the main
when satisified that nothing breaks.
IMHO, this would give us some new leverage during this freeze phase.
I also think it would be better to include the untested versions as
part of the unstable/stable tree, but dselect gets confused with
this--I don't know how apt responds. Adding untested, mirroring it,
and making it part of the packaging hierarchy seems like a short step
from where we are.
Reply to: