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

Re: Proposal: Why not use testing-proposed-updates?

On Sat, Feb 02, 2002 at 02:13:11PM +0100, Martin Schulze wrote:
> Jonathan McDowell wrote:
> > [Credit for the writing of this goes to Robot101. The ideas where hashed
> > out by a number of us though. We're fully expecting someone to turn
> > round and tell us exactly why it won't work. Robert isn't on
> > debian-devel so please Cc him on replies. I am however, so I'll read it
> > onlist.]
> > 
> > Our current release paradigm is one where non-buggy, arch-synched and 
> > dependency-satisfied packages work their way from unstable to testing 
> > after a suitable cooling off period. The principle is that this makes 
> > testing a known less-buggy platform, to make it easier to release with 
> > simple snapshots. However, this has several flaws:
> >  * As stable becomes more and more out of date, more and more people 
> > will turn to using testing. With the increased usage, it is inevitable 
> > that bugs will be filed against testing itself, taking it further from 
> > the ideal bug-free snapshottable release platform that we desire.
> That's true with stable as well.  However, since the package is
> probably as broken in unstable as it is in testing, uploading to
> unstable with a higher priority should work as well, no?

What if the version in unstable has a later version than the one in
testing and has additional problems? Then you need to fix all of these
additional problems as well as the problem in testing in order to get it
into testing without any detriment to testing. We allow serious bugfixes
in stable at present.

> > Bearing these in mind, the idea of having another way to get updates 
> > into testing may not be as bizzare as it sounds. The proposed
> > testing-proposed-update release (which already seems to exist, but I do
> > not know the conditions of it's use) would be subject to the same
> > criteria to progress into testing as packages in unstable are.
> However, there's still the problem with library dependencies.  This
> could be circumvented by uploading to woody-proposed-updates.

Um, testing-proposed-updates would be a symlink to
woody-proposed-updates at present, yes.

> I'm not sure how useful this is, though, since a) there are probably
> no woody buildd's, hence packages will get out of sync and b) many
> developers run unstable and uploading into testing with library
> depencencies only fulfilled in unstable, will get the situation worse.

We have the same problem with uploads to stable. Uploads to t-p-u would
have to be built against testing libraries in the same way as uploads to
stable have to be built against stable libraries.

The lack of woody buildd's is indeed one of the problems with the
proposed scheme. However with regards developers many also run stable or
testing and have unstable chroot's for the purposes of development. The
intention is that most developers wouldn't need to be doing uploads to
t-p-u anyway (because of course everyone aims to have perfect packages
in unstable that will progress to testing automatically ;).

buildd people: I've seen claims that one of the major problems is a lack
of eyes for buildd reports. If we assume that the number of packages
that need to be built for t-p-u is relatively low then is it possible
that with a few more people buildds could exist for it? Or are the
current buildd machines already all overloaded in terms of work /

> > However, the conditions for upload would be similar to those for when 
> > stable/testing freezes. Only security updates, and RC bugfixes, are 
> > allowable into testing-proposed-updates, and new upstream versions only 
> > allowed when they are only for these purposes.
> There also needs to be a team that watches uploads into this
> distribution in order to pick up valid packages and reject broken
> packages.  Also, some people need to watch to get packages in sync
> again.
> I really fear library problems and out-of-sync packages with this
> attempt.

I don't see that library issues are any worse than uploads to stable.
I'm not quite sure what you mean by out-of-sync packages though. You
mean out of sync with updates from unstable?

> Imho this should not increase Anthony's load,

Absolutely; it wasn't the intention to claim that anyone else had to
make this happen.

> so new and confident people have to be involved.

> > Another massive advantage of this is that it becomes possible to upload 
> > security updates to testing without them being subject to being held up 
> That would indeed be an advantage.
> > This dual-feed approach to testing should bring us much closer to the 
> > ideal of having a testing that remains bug-free and current enough so 
> > that a 6-monthly snapshot release can be considered a reality. The 
> > bugsquash parties and NMUers could feed fixes into t-p-u and fix RC bugs 
> > quickly without trampling on the maintainer's toes with the latest 
> > unstable version, which is where I'm assuming the most effort of a 
> > maintainer is dedicated.
> Still this does not address broken boot-floppies, boot-floppies that
> require packages from unstable, out-dated installation documentation
> etc.

It's certainly not the complete answer to Life, the Universe and
Everything, but I feel that it's a step in the right direction.

> Without people actually working on it, it's just the (n+1)th useles
> proposal, I fear.

I wouldn't have sent the mail if I wasn't prepared to put in some

Currently I run a couple of Debian based shell servers (I run some other
Debian servers too, but it's the shell servers that particularly raise
the issue). They both run stable at present, because they're remote and
I need to be able to be sure they're secure and reasonably stable.
However I'm finding more and more that users want packages installed
that have been available for months (or sometimes over a year) but due
to the fact that stable is over 1.5 years old aren't available. So I
need to rebuild. My co-admin and some of my users have been trying to
persuade me to run testing. If I do so then I end up having to track all
the security issues for any package installed myself and also having to
keep an eye on stability. I can't be the only person in this position.
Therefore it makes sense that if I'm going to do the work it helps
Debian as a whole and also hopefully others help too, so that if I
happen to be busy, hungover or dead then wheels do keep moving and my
boxen don't all get rooted/fall over in a heap.

> > This could be considered what should/would happen when testing freezes. 
> When testing freezes, there are possibilities to upload packages into
> it.  Remember the test-cycles?

Vaguely. It's been so long.

> A new upload implies a new test cycle, which is another delay etc.

Absolutely. But new uploads during freeze should only be for RC bugs
AIUI. Which we /want/ in, even if it does mean another delay.
> > However, this looks quite unlikely while testing remains buggy, and this 
> > remains hard to fix while unstable lives up to it's name, and tracks the 
> > cutting edge - as it should. There's no reason we can't have t-p-u as a 
> > way to get simple and security fixes into testing fast, so that 
> > releasing needn't be such a hassle.
> Are you able to name problems that would require such a setup, which
> are not able to be solved with the current setup?  Ignore security for
> a moment.

I can't think of any existing problem (though maybe someone else can
provide an example).

Security is a major one in my eyes, but even discounting that there's
the fact that we will get more bugs raised against testing as more
people use it (and more people are) and we need a way to be able to fix
these bugs in the event that the unstable version of the package has
moved on and inherited more bugs that aren't so easy to fix.

Consider what happens if I upload package foo to unstable and 5 people
use it in the mainline case and have no problems and it goes into
testing. A new and great version comes out that I package and upload
again and it turns out that 1 of those 5 people uses it slightly
differently than the rest of us and finds a major bug that's no so easy
to fix. Meanwhile the version in testing gets used by more people who
aren't all using the mainline and who perhaps find a major bug that's
easy enough to fix. There's no way to fix that bug at present that I
know of without uploading a new package to unstable that fixes both
major bugs.


This isn't an office. It's Hell with fluorescent lighting.

Attachment: pgp_uau2E070O.pgp
Description: PGP signature

Reply to: