Re: >2000 packages still waiting to enter testing, > 1500 over age

[Sven Luther <luther@dpt-info.u-strasbg.fr>]

On Fri, Apr 18, 2003 at 02:17:41AM +1000, Anthony Towns wrote:
> On Thu, Apr 17, 2003 at 02:05:59PM +0200, Sven Luther wrote:
> > On Thu, Apr 17, 2003 at 09:33:32PM +1000, Anthony Towns wrote:
> > > On Thu, Apr 17, 2003 at 12:01:57PM +0200, Sven Luther wrote:
> > > > Well, i personnaly think that in some case it would be much simpler to
> > > > _remove_ the packages from testing, and let the new versions enter
> > > > testing as they can. 
> > > Yes, this generally happens. It's not really a good thing though -- it
> > > screws up people who are using / relying on the packages being removed;
> > > they'll get complaints from apt-get every time they try to upgrade until
> > > things get cleaned up. cf libc6 and php recently, eg.
> > Yes, this is the general case, and i fully understand this.
> > But in the particular case, the two blocking packages are really seldom
> > used (two developpment packages only) and most people don't use the
> > ocaml 3.04 that is in testing, but ocaml 3.06 backports.
> > 
> > I think this is one of the cases where the maintainer has more idea of
> > what is going on than the release manager, 
> 
> Considering the release manager hasn't looked at it in any detail at all,
> that seems like a reasonable conclusion. Which package/s is it okay to
> drop for ocaml?

Well :

| Delivery-date: Tue, 01 Apr 2003 15:46:52 +0200
| Old-Return-Path: <luther@dpt-info.u-strasbg.fr>
| To: submit@bugs.debian.org
| Cc: debian-ocaml-maint@lists.debian.org, aj@azure.humbug.org.au
| Subject: asking for removal of libpgsql-ocaml and ocamlsdl from testing.

I CCed you the bugreport where i explain everything, but the packages are :

  libpgsql-ocaml

  ocamlsdl

These are the source packages.

I am not _entirely_ sure that this would be enough though, but as far as
i can see, this would be it. I checked the testing dependencies of each
of the involved packages manually, and also the conflicts. I don't think
there are conflicts from other packages.

> The "upload to testing-proposed-updates" thing people have mentioned in
> this thread works too, although each uploaded source packages needs an
> explicit approval from the RM (or similar) to get in in that case, which
> we're not really doing at the moment.

No, it would not work, because you need to build them either with
testing + bit of unstable or unstable + bit of testing, and altough i
can do that easily enough, the autobuilders will be less than happy with
it, and i don't think the debian-admins would accept to install bit of
unstable into the testing chroots.

That said, i think it is a nice idea, and maybe the autobuilders could
be made to understand such requirement. This would be the best idea on
how to do this.

Also, i think that the testing scripts don't consider
testing-proposed-updates right now, do they ?

> > That said, the real question is what testing is for :
> >   o To help prepare the next release, in which case we should remove
> >     conflicting packages.
> >   o So people can test the next release without being subject to random
> >     unstable breakage. In this case, we should not remove the
> >     conflicting packages.
> 
> It's for both. Which is to say "we should remove the conflicting packages,
> but only as a last resort".

Yes, on a case per case basis, after agreement of all the involved
maintainers and the RM. It is just as you didn't respond to my mail, nor
did any of the ftp master act on my bug report, nor did anyone even
aknowledge it, i felt abandoned ...

I still feel that the testing script update should be clarified and that
more information about the real reason for a package to be blocked in
the PTS, since a lot of user come complaining or wondering about why a
package is a valid candidate since month but not yet in testing. Sadly,
i don't speak python ...

Friendly,

Sven Luther