[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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).


[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

See also:

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: