Re: More 5 november in the release schedule

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Marvin Renich writes ("Re: More 5 november in the release schedule"):
> Emilio Pozuelo Monfort <pochu@debian.org> [161108 16:01]:
> > It is true for other removals from testing, which can happen in two different ways:
> > 
> > - The package was removed from unstable
> > - The package was hinted for testing removal by the release team
> > 
> > Since britney doesn't enforce (atm) that build-dependencies are
> > satisfiable in testing, those two cases can cause this
> > problem. However in the former case, rdeps should get a FTBFS bug
> > so you will know about the problem, and the latter is not very
> > frequent.
> 
> But wouldn't the FTBFS bug be filed after the removal of the build-dep,
> so that it is too late for the maintainer to assist in keeping the
> build-dep in the archive?  I thought this part of the thread was about
> getting notification of pending, not already happened, removals so that
> help could be directed in time to keep the package in the archive.  Do I
> misunderstand?

We've discussed several corner cases here and it's still not quite
clear if a maintainer would always get an appropriate heads-up.

It would be helpful if the release team would confirm that if

 - a contributor is trying to keep a package in testing;

 - the contributor has paid reasonable attention to the available
   information channels (tracker.d.o, PTS subscription, BTS, say) for
   the package they care about, but these did not provide timely
   notification that the package was at risk of falling out of
   stretch;

 - the contributor fixes the underlying issue(s) expeditiously;

the Release Team would consider favourably a request for an exception
(to whatever policies stand in the way of fixing the problem in
stretch).

I think such a statement would greatly alleviate some of the concerns
we have seen here.  It would be valuable for this reason even if we
currently think that such a scenario is very unlikely in practice.

If it turns out to be a more common problem and there are many
packages affected, then this would mean delays to the stretch release,
indeed.  But it would also highlight where the real problem is - ie,
not with the maintenance of the individual packages, but with our
processes for ensuring that the right information gets to the right
people.  If this _is_ a problem for stretch then we need to improve
our processes for buster, rather than throwing stuff out of stretch.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.