Re: More 5 november in the release schedule
On 08/11/16 11:05, Christian Seiler wrote:
> On 11/08/2016 08:31 AM, Scott Kitterman wrote:
>> On Tuesday, November 08, 2016 06:19:36 PM Brian May wrote:
>>> Christian Seiler <christian@iwakd.de> 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?"
Right. We want auto-removals to be useful for the release process, so that we
don't end up with a thousand of RC bugs in testing when we freeze, most of them
on packages that nobody cares about, not even their maintainers.
However, we don't want auto-removals to drop your package behind your back. If
that happens, that's a bad thing and you should let us know so we can fix
things. auto-removals should notify the maintainer in advance, and only act
after a reasonable period of time.
The "packages can't re-enter testing during the freeze" is an incentive so that
maintainers don't wait to fix a package after a few months, and so that we don't
have to go and remove them manually. This way you know that something is going
to happen if you don't act, yet you should have a reasonable amount of time to
do something. Hopefully this helps have a short(er) freeze, which is good for
everyone.
> 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)
Exactly.
Cheers,
Emilio
Reply to: