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". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/525af8ba.30...@thykier.net
