Re: Preparing the next Release
* Martin Schulze:
> When there is no cups for amd64 in the release, it does not matter
> whether it FTBFS on amd64 or not, for example.
I believe that such FTBFS bugs are already deemed "important"; they
are not release-critical. A lot of porters who file FTBFS bugs
disagree, but this doesn't make them right.
> While I would love to have the exact set of packages on all
> architectures, I need to accept the fact that on some architectures
> some packages just don't work or cause an FTBFS we are unable to fix
> in time for the release.
Some of these bugs will be discovered only after the release, anyway.
> This is a bit exagerated, but I hope you'll get an idea of what I was
> trying to express. When the data los *can* happen in only certain
> quite uncommon circumstances and the rest of the system and of the
> package works fine, I'm not too sure we should delay the release to
> get this problem fixed before.
Maintainers tend to decrease the severity of the corresponding bug
reports below RC level on their own. I believe we generally do this
for web browsers, for example, which seems to be the right thing to