Re: Bug#109577: version 1.23 available
On Tue, Aug 28, 2001 at 07:19:47PM +0100, Philip Blundell wrote:
> >Testing in its current state has potential to be more unstable than
> >sid, has already been, and will be again if the process does not
> >evolve. My idea to work around it is expressed above, but I'm quite
> >sure I overlooked some things - as the problems I describe were
> >overlooked originally.
>
> I'm not at all convinced that allowing direct uploads of packages into testing
> (and hence effectively forking packages) is going to help with stability. If
> people can upload to testing directly, it will be very difficult to stop
> maintainers from making inappropriate uploads, either accidentally or
> deliberately.
Ideally only fixes to RC bugs should go through this testing-fixes
queue (that would be somewhat similar to stable-updates), and this,
only if there are already risky developments in 'unstable'.
> The whole reason for having `testing' is that packages can only
> get into it by meeting a particular set of criteria, or by manual intervention
> from ftpmaster.
I would state it otherwise. The goal of 'testing' is to have a dist
whose stability makes it as closer to be releasable as possible, with
contrast to 'unstable'. The set of criteria is just a means of
getting there.
> In the case of your console problem, you could have fixed testing by just
> re-uploading the old version of the package with a newer version number (using
> an epoch if necessary) and "urgency=high".
It may seem at first glance. But that unnecessary slows down the
testing of 'unstable', and that requires to support downgrading in
packaging (in the console case, the package is complex enough that I
wouldn't even think of doing that). What if, for example, some sid
users start to use new features of e2fsprogs 1.23 in unstable
(extended attributes and external journal), and something appears
wrong with 1.22 in testing ? I'd be forced to use an epoch to get
1:1.22-x >> 1.23-1 (which is an abberation, and not what epochs are
for), and those users would maybe get unusable systems on upgrade,
because the downgrade was shown as an upgrade. I'm quite sure there
are plenty of other cases with no way out.
BTW, attentive readers of this list already noticed I'm currently
somewhat wondering about introducing e2fsprogs 1.23 in unstable,
partly because of this.
Regards,
--
Yann Dirson <Yann.Dirson@fr.alcove.com> http://www.alcove.com/
Free-Software Engineer Ingénieur Logiciel-Libre
Free-Software time manager Responsable du temps Informatique-Libre
Reply to: