Re: Alternative proposal: reaffirm maintainers technical competence over the software they maintain
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 think that this would be a significant step backward in the way we
> promote consistent technical practices in all Debian packages.
Promoting consistent technical practices is policy's purpose, not the
release team's, surely?
>From what I can see, policy currently (version 3.9.6.0) covers init.d
scripts and upstart, but doesn't mention systemd or unit files. That
seems suboptimal to me...?
Cheers,
aj
Reply to: