Re: More 5 november in the release schedule
On 11/08/2016 08:31 AM, Scott Kitterman wrote:
> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>> Christian Seiler <email@example.com> writes:
>>> Why? Any package currently in testing still has time to enter
>>> (until roughly end of this year), so it's not like there is no
>>> heads-up for people. And RC bugs don't lead to immediate
>>> removal from testing, you still have quite a bit of time until
>>> they actually cause removal of a package.
>> The problem is if the maintainer is not responding to RC bug reports,
>> and you don't realize a package you depend on has RC bugs. This happened
>> several times to me during the last freeze.
> I seem to get email when a package I maintain is marked for autoremoval
> (regardless of whether it is an issue with my package or an rdepend). That
> and it showing up on your DDPO Packages overview ought to be enough to be
> forewarned, I would have thought.
Yes, especially since autoremovals are not instantaneous, but for
packages with rdeps (and the rdeps themselves) will happen at
least 30 days in the future - and you will get an email in time.
(For packages without rdeps it's 15 days. Plus IIRC a week delay
after a bug was initially marked RC before autoremoval is even
triggered, but I might be wrong about that last part.)
30 days within the deep freeze should be plenty enough - and as I
said: if the problem is more complicated, just talk to the release
team _while the package is still in testing_.
The goal of autoremovals is to provide an incentive for people
to deal with problems in their packages _early_. My experience
with the release team is that they are very willing to consider
many different solutions if you talk to them early enough. They
just don't want people coming along 4 months into the freeze and
telling them "er, yeah, my package got removed 3 months ago, and
I just didn't care about it until now, and during the entire
freeze it didn't really receive much testing, but pretty please
could it be included again?"
And as I said previously: if a maintainer of a dependency of yours
doesn't care: NMUs for RC bugs have a far lower threshold - even
0-day NMUs are possible if the maintainer is really completely
asleep. (DevRef 5.11.1)