Re: Raising priority of Debian packages
On Sat, Aug 30, 2014 at 09:30:17AM -0700, Russ Allbery wrote:
> Gerrit Pape <pape@dbnbgs.smarden.org> writes:
> > [0] Actually policy 2.5 requires to additionally file a RC bug to the
> > high priority package with the added dependency to prevent it from being
> > migrated to testing until the override decision has been made.
>
> Policy does not address RC bugs at all. The determination of whether a
> bug is RC is the province of the release team, not Policy.
>
> Policy 2.5 says that appropriate priorities is a must, but does not say
> whether this would be a bug in the depending package or the package being
> depended on,
Me personally as a maintainer, when I plan to add a new dependency on a
lower priority package to a high priority package, I'm aware that this
will introduce a new violation of Debian policy into the archive.
Reading the BTS documentation on severities
serious
is a severe violation of Debian policy (roughly, it violates a must or
required directive), or, in the package maintainer's or release
manager's opinion, makes the package unsuitable for release.
I either first try to get the priorities of the involved packages
straight, or, when uploading with the new dependency added, feel that I
shall file the serious bug against my own new packages version. After
all this very upload is the change to the Debian archive that introduces
the new priority conflict, and can wait a bit longer before migrating
into testing. To me personally it's clear to which package the bug
report belongs, without having policy telling me.
But the RC bug thing actually is not what I'm after, let me iterate here
though that I have the feeling the Debian culture is changing to somehow
fear RC bugs, and also flames so that more and more things are done
without making the information publicly available. I don't like this
change.
Bug reports, including release critical ones, are a good thing! They
help us to improve our distribution and make high quality releases, we
should utilize them where appropriate!
When having such bugs filed, and the release team decides they shall not
be release critical, this shall be made public, the severities of
corresponding bugs adjusted, and everything is fine and transparent.
Currently I'm not aware of such a release team's decision.
Back to my mail, the main content and not the footnote. What I'd like
to see is more transparency (1) in the process of raising package
priorities and (2) in the information of existing priority conflicts in
the archive.
For (1) I share my view with fellows on this list, and suggest how this
can be achieved through single maintainer's actions. For (2) I
suggested a change to policy that helps us to get a comprehensive view
on current priority conflicts that actually have an impact. The
optional<->extra conflicts just dilute it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759260#62
> Also, I'll reiterate what I said on debian-policy on this topic: the
> current Policy discussion of priorities is deceptive, since it implies
I don't think the discussion on the issue I raised is deceptive
> that package maintainers are responsible for determining the priority of
> the package. This is not the case; ftp-master determines the priority of
> packages, with input from package maintainers. Policy discussion of
> priorities really needs some substantial revision to account for that, for
> the fact that conflict-free optional has not realistically been a project
> goal for some years, and to be clearer about just what we want to use
> priorities for.
and not connected to this, which sounds like an entirely different issue
that just happens to target the same area in the policy document.
Regards, Gerrit.
Reply to: