Re: Bits from the Release Team (Jessie freeze info)
On 2013-10-13 19:41, Bernd Zeimetz wrote:
> Hi,
>
>> We are happy to announce that we will freeze Jessie at 23:59 UTC on the 5th
>> of November 2014.
>
> thanks for annoucing that early and for your work!
>
You are welcome. :)
>> [...] * Proactive automated removals 3 months into the freeze. - Note that
>> bug-free packages will be removed if they (build-)depend on a RC-buggy,
>> non-key package.
>
> Could we get a warning about such removals before they are scheduled? Like at
> least one week before? Having an eye on all packages all my packages
> build-depend is something which would be great to avoid ;)
>
We could "just" finish the finish the freeze within 3 months and not
have this problem at all! XD
Honestly, I am hoping we can have such a list of packages be found in an
automatically. At the current time, about 3k of all source packages
builds at least one key package vs. a total of 20k-21k source packages
(in sid). A quick estimate suggests that we got over 80% source
packages that could be candidates for such removals.
If I have to find those manually, I will probably end up being pretty
sad (and unable to do it on a regular basis - which would somewhat
defeat the purpose of this idea).
>> [...]
>
>> - Native packages are at a disadvantage here, since all uploads of native
>> packages are considered a new "upstream" version.
>
> So whats the "fix" for that? Migrating native packages to non-native ones does
> not always make sense.
>
The quick fix is to not do these "carte blanche"-unblocks at all, which
is the status-quo/current plan. Obviously, if the upload of a native
package fits the freeze policy, it can still receive a manual unblock.
But honestly, I would prefer if we didn't need to resolve this gray
area at all. If people are trying to rely on "carte blanche"-unblocks,
they might be optimising for the "wrong thing". Having your packages
ready and *in testing* before November is really a much simplier and
easier for all parties involved. Bonus if they are 100% bug free too.
On a related note: I would recommend people to get accustomised to
interpreting the excuses from Britney[1] and keeping an eye out for
"Valid candidate"-packages that are not migrating despite being in that
state for a couple of days. Even if we were to do "carte
blanche"-unblocks, your package must still be able to migrate as-is,
which apparently caught many people by surprise during the Wheezy cycle.
This is actually another argument for not doing these "carte
blanche"-unblocks. We had quite some difficulty in conveying our
intention behind them. People seemed to have quite a different
understanding of how they were "supposed to work".
Side note: Should you be fed up with Britney's (un)helpful exucses-page,
you are more than welcome to get in touch with us and to help us write
patches to classify the problems better.
>
>> [...] - It should also go without saying that embedding a new upstream
>> release in a patch just to get a such "carte blanche" exception is also
>> considered abuse.
>
> What about bugfix point-releases from upstream, like postgres and other sane
> upstreams do it?
>
>
> thanks & cheers,
>
> Bernd
>
>
If you are doing a new point release, you ought to bump the upstream
version of your package. As soon as you do that, it would no longer be
applicable for a "carte blanche" unblock.
The note referenced above is about embedding all the upstream changes
in a "Debian patch" and only bumping the Debian revision (while keeping
the "upstream version" unchanged). Basically, it is a "don't game the
system"-rule (like the "don't abuse urgency"-rule).
~Niels
[1] They are admittedly not always very helpful to
"non-Britney-developers". Basically, people tend to get confused by
"out of date"-binaries and side-effects caused by having "out of
date"-binaries.
See also:
http://nthykier.wordpress.com/2013/07/14/britney-excuses-ood/
"""
The tricky part of an “out of date”-excuse is that Britney simply
identifies a symptom and not a cause.
"""
Side-effects of "out of date"-binaries may include "RC bugs fixed in sid
is not considered fixed by Britney" and "package not migrating to testing".
Reply to: