On 21/10/14 at 08:21 +0000, Anthony Towns wrote:
> On Mon, Oct 20, 2014 at 11:55:30PM +0200, Lucas Nussbaum wrote:
> > On 20/10/14 at 22:26 +0200, Arno T?ll wrote:
> > > That's - I think - a good default and affirms Debian's point of view
> > > that the respective maintainers can judge best what's a good requirement
> > > for their packages. Finally I encourage everyone to focus on the
> > > connotation in Luca's amendment. It allows maintainers to tie their
> > > software to a particular init system only as a last resort when
> > > absolutely necessary - not by pure choice, or by laziness.
> >
> > I disagree with this interpretation.
> > We have processes in place in Debian to deal with such last resort situations:
> > - someone opens an RC bug against the package, stating why it is
> > unsuitable for release
> > - the release team reviews the bug, and might (or not) mark it with the
> > jessie-ignore tag
>
> This seems mistaken to me -- issues shouldn't have to be release critical
> to be reviewed, or go through the release team. I would have said the
> process should be:
>
> - discussion happens on -policy or -devel about what the best approach
> on some issue is
> - someone opens a bug against the package that takes a less effective approach
> - the maintainer reviews the bug and takes whatever action they consider
> appropriate
> - further discussion happens on the bug, -policy or -devel or similar
> - as a last resort, the matter is escalated to the tech ctte for review
>
> I don't think there's a need for that process to involve blocking a
> package from release, or any necessity to distract the release team from
> coordination issues to participate in resolving technical conflicts.
I understand this GR amendment as:
- the policy is that packages must support the default init system
- but as a last resort option, the maintainer can decide to drop this
support
This is a situation where everybody agrees that the package does not
meet our policy and that an RC bug is appropriate, but where there's no
real technical solution. That is quite different from situations where
there's disagreement that something is actually a problem, that the
problem is severe, or on the proper course of action (where the process
you describe is appropriate).
Currently, in this situation, the maintainer can ask the release team to
decide whether:
(1) the package should be removed from testing due to this problem
(that's the default choice)
(2) the package can stay despite this problem, using a work (e.g.
require another init system)
My point is that this proposal transfers this decision from the release
team to the maintainer, for the specific case of the support for the
default init system.
Lucas
Attachment:
signature.asc
Description: Digital signature