Re: Proposal: Why not use testing-proposed-updates?
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?
> 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. 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.
> 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. Imho this should not increase Anthony's load, 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.
Without people actually working on it, it's just the (n+1)th useles
proposal, I fear.
> 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? A new upload implies a new test cycle,
which is another delay etc.
> 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.
Regards,
Joey
--
All language designers are arrogant. Goes with the territory...
-- Larry Wall
Please always Cc to me when replying to me on the lists.
Reply to: