Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Josh Triplett
On Wed, 18 Nov 2020 17:33:26 + Matthew Vernon  wrote:
> This bug report relates specifically to bugs in the network-manager
> package (#921012, #964139) but has broader implications, particularly
> around what it means to "support the efforts of developers"[0] working
> on support for alternative init systems (I will talk about sysvinit here
> without loss of generality to other non-systemd init systems).

First, as a point of order (for which some authoritative guidance from
the Secretary, CCed, would potentially prove useful): while the
technical committee is empowered to handle various types of disputes (up
to and including overruling an individual developer if necessary), I do
not believe it falls within the scope of the technical committee to
override a decision already decided by a project-wide GR, or to
"interpret" the text of a GR issuing a nontechnical policy document in
ways that may undermine the decision made in that GR and document.  Any
interpretation of the text of the GR would need to be based on the text
and intent of the GR. (Intent could include discussion at the time, but
would notably include the text of other options that did not prevail, as
well as the status quo at the time that motivated a GR to change.)
Changing that intent would require either another GR, or (per specific
provisions included in the winning GR option) consensus among the
project, not a TC ruling.

Concretely, the GR explicitly acted by "Using its power under
Constitution section 4.1 (5)", which is the power to "Issue, supersede
and withdraw nontechnical policy documents and statements.". The
Technical Committee does not have such "nontechnical policy documents
and statements" within its ambit. Any interpretation of 'what it means
to "support the efforts of developers" working on support for
alternative init systems' would thus be an interpretation of such a
nontechnical policy document.

Thus, I would suggest that the technical committee should decline to
rule on any matters already decided by the GR. This does not preclude
the TC from offering advice, or potentially facilitating dispute
resolution if asked to do so, or even as a *last resort* overruling a
developer on a specific technical matter (if doing so does not go
against the GR), but I don't believe it's within the scope of the TC to
relitigate the GR to mandate support for alternative init systems. Any
potential ruling here would need to avoid attempting to supersede the
GR.

That furthermore means that the question asked in the subject ("Should
maintainers ...") is much, much broader than any question that should be
ruled upon in this issue (if any). The GR answered a closely related
question, namely whether maintainers should be *forced* to accept
support for alternative init systems, with a definitive "no".


While the GR did explicitly state that the "position may evolve as time
passes without the need to resort to future general resolutions", that
provision would require project consensus in order to evolve such a
position. I don't think there's been any indication that consensus has
substantively changed in that regard since the time the project passed
that GR. In the absence of such consensus, the GR stands as the decision
of the project developers.

One major aim of the GR (https://www.debian.org/vote/2019/vote_002) was,
in large part, to settle with finality many ongoing case-by-case
disputes about alternative init system support, and to allow developers
to work in peace without having to continuously deal with this disputes
of this type; in short, the goal (by proponents of many different
positions) was to settle init system questions in one direction or
another, in the hopes that the project would abide by the decision once
made, rather than expending ongoing energy and attention relitigating it
on a case-by-case basis.

The GR contained options for requiring ("must"), or even strongly
encouraging ("should"/"important"), developers to maintain sysvinit
support; those options did not win. The winning option, instead, issued
a policy statement that allowed continuing exploration and
experimentation with alternative init systems, but specifically stated
that "Those interested in exploring such alternatives need to provide
the necessary development and packaging resources to do that work.", and
furthermore left it to maintainer discretion ("may", not "should" or
"must") whether to include such support in packages. There were
certainly more than enough options on the table to allow the developers
by way of GR to issue a stronger statement, and the developers declined
to do so. And it's even more emphatically clear that "Further
Discussion" was not the desired outcome.

Per Debian Policy: "Guidelines denoted by may (or optional) are truly
optional and adherence is left to the maintainer’s discretion." Also see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948115 , which
implemented the GR in Debian Policy.

Any inclusion of work into a 

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Philipp Kern
On 18.11.20 18:33, Matthew Vernon wrote:
> Package: tech-ctte
> Control: block 921012 by -1
> Control: block 964139 by -1
> X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk
> 
> Dear Technical Committee,
> 
> This bug report relates specifically to bugs in the network-manager
> package (#921012, #964139) but has broader implications, particularly
> around what it means to "support the efforts of developers"[0] working
> on support for alternative init systems (I will talk about sysvinit here
> without loss of generality to other non-systemd init systems).
> 
> In brief:
> 
> #921012 is about changing network-manager to Depend upon "default-logind
> | logind" rather than libpam-systemd
> 
> #964139 is about restoring the removed network-manager init script which
> was removed from the package. There is no suggestion that the init
> script was buggy
> 
> Both changes are necessary for it to be possible to install
> network-manager on a sysvinit system; it is going to be hard to use
> Debian without network-manager.
> 
> Both bugs have sat open for extended periods with no input from the
> maintainer; so I prepared an NMU and uploaded it to DELAYED/14 as well
> as making an MR on salsa[1].
> 
> The NMU was declined, on the basis that removing the init script was not
> a mistake; I'm not aware of any rationale being provided beyond that for
> refusing either patch.
> 
> I'm afraid the effect of this is that the maintainers of this package
> are making it impossible for other developers to enable support of
> sysvinit. There are people[2] who will (and have) test compatibility
> changes, help with issues with sysvinit scripts, and so on, but those
> efforts are in effect being stonewalled.
> 
> The effect of this, and equivalent behaviour in some other packages, is
> that it is going to be impossible to make a useful Bullseye for users
> who want to use sysvinit.
> 
> I (and a couple of other interested parties) have approached the DPL
> about this matter on a number of occasions this year, and have tried to
> follow their advice where possible. I regret that it has proved
> necessary to involve the technical committee.
> 
> I invite the technical committee to rule that:
> * The network-manager init script should be restored
> * Network-manager should Depend: on default-logind | logind rather than
> libpam-systemd
> * Similar init-compatibility changes should not be blocked by package
> maintainers unless they are defective on their own merits
> * These changes be made in time to be effective in Bullseye

I know it was mentioned back in the day, but trying to re-ask it now:
Wouldn't it be possible to ship init scripts for compatibility purposes
from a sysvinit (or maybe a sysvinit-support) package? This would be the
inverse of what happened back when systemd was introduced, which was
about shipping service files that superseded existing init scripts.

I understand that you might not want that maintenance burden, however it
seems like the network-manager maintainers might not want that
maintenance burden either.

That obviously would not solve the dependency issue, where the (not
copied) claim of the maintainers is that there is no interface equality
between what you suggest and what they think is appropriate. The last
message in the bug suggested dropping a file in network-manager's config
 directory to disable a certain feature. With hooks it's clearly
acceptable to drop files into configs of other packages and one could
argue that a configuration directory is a similarly acceptable interface
to reuse from another package. Maybe there'd be an amenable way if the
interaction is properly defined? Like a support package doing that
providing some pseudo-package that can serve as an alternative dependency.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature


Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Felix Lechner
Hi,

On Wed, Nov 18, 2020 at 10:21 AM Matthew Vernon  wrote:
>
> I invite the technical committee to rule that:

What a great read! This message must be among the best prepared, and
most polite, to come before the committee.

Kind regards,
Felix Lechner



Bug#971515: Status as of last tech-ctte meeting

2020-11-18 Thread Sean Whitton
Hello all,

On Wed 18 Nov 2020 at 11:36AM -06, Gunnar Wolf wrote:

> So... It's not like we reached a conclusion, but I do feel the meeting
> was interesting and the discussion very much worthy. Yes, this will
> surely end up in reinforcing the notion that the Technical Committee
> is a slow and bureaucratic beast :-) But... well, I'll stop
> apologizing. Only some minutes to go before the meeting, and I want to
> give the rest of the Committee the opportunity to check if I didn't
> misrepresent them or skip too much of their opinion.

Thank you for this summary.

At today's meeting one point which we thought was missing from this
summary was that no-one on the committee has any appetite for overruling
the package maintainer, so it is very unlikely that will be the outcome
of this bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Matthew Vernon

Package: tech-ctte
Control: block 921012 by -1
Control: block 964139 by -1
X-Debbugs-CC: debian-init-divers...@chiark.greenend.org.uk

Dear Technical Committee,

This bug report relates specifically to bugs in the network-manager 
package (#921012, #964139) but has broader implications, particularly 
around what it means to "support the efforts of developers"[0] working 
on support for alternative init systems (I will talk about sysvinit here 
without loss of generality to other non-systemd init systems).


In brief:

#921012 is about changing network-manager to Depend upon "default-logind 
| logind" rather than libpam-systemd


#964139 is about restoring the removed network-manager init script which 
was removed from the package. There is no suggestion that the init 
script was buggy


Both changes are necessary for it to be possible to install 
network-manager on a sysvinit system; it is going to be hard to use 
Debian without network-manager.


Both bugs have sat open for extended periods with no input from the 
maintainer; so I prepared an NMU and uploaded it to DELAYED/14 as well 
as making an MR on salsa[1].


The NMU was declined, on the basis that removing the init script was not 
a mistake; I'm not aware of any rationale being provided beyond that for 
refusing either patch.


I'm afraid the effect of this is that the maintainers of this package 
are making it impossible for other developers to enable support of 
sysvinit. There are people[2] who will (and have) test compatibility 
changes, help with issues with sysvinit scripts, and so on, but those 
efforts are in effect being stonewalled.


The effect of this, and equivalent behaviour in some other packages, is 
that it is going to be impossible to make a useful Bullseye for users 
who want to use sysvinit.


I (and a couple of other interested parties) have approached the DPL 
about this matter on a number of occasions this year, and have tried to 
follow their advice where possible. I regret that it has proved 
necessary to involve the technical committee.


I invite the technical committee to rule that:
* The network-manager init script should be restored
* Network-manager should Depend: on default-logind | logind rather than 
libpam-systemd
* Similar init-compatibility changes should not be blocked by package 
maintainers unless they are defective on their own merits

* These changes be made in time to be effective in Bullseye

Regards,

Matthew

[0] From the wording of the winning option in the 2019 Init systems GR
[1] https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/7
[2] e.g the mailing list debian-init-divers...@chiark.greenend.org.uk of 
people who are more than happy to help with this sort of thing




Processed: tech-ctte: Should maintainers be able to block init compatibility changes?

2020-11-18 Thread Debian Bug Tracking System
Processing control commands:

> block 921012 by -1
Bug #921012 [network-manager] network-manager: change dependency on 
libpam-systemd to libpam-systemd or libpam-elogind
Bug #960780 [network-manager] Network-manager: please Depend on libpam-systemd 
| logind
921012 was not blocked by any bugs.
921012 was not blocking any bugs.
Added blocking bug(s) of 921012: 975075
960780 was not blocked by any bugs.
960780 was not blocking any bugs.
Added blocking bug(s) of 960780: 975075
> block 964139 by -1
Bug #964139 [network-manager] network-manager: Please restore removed init 
script.
964139 was not blocked by any bugs.
964139 was not blocking any bugs.
Added blocking bug(s) of 964139: 975075

-- 
921012: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921012
960780: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960780
964139: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964139
975075: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#971515: Status as of last tech-ctte meeting

2020-11-18 Thread Gunnar Wolf
Hello world,

When we had our last tech-ctte meeting, 2020.10.21¹, I volunteered to
write up a summary of our positions regarding this bug. Then... Well,
life happened, and I have not had the time to sit down and write until
today -- A couple of hours before our next meeting. Several other
discussions have happened as well, most notably, the article by
Jonathan Corbet on this issue in LWN².

¹ http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-10-21-17.58.html
  
http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-10-21-17.58.log.html
² https://lwn.net/Articles/835599/

# Vendoring: Impedance mismatch with our long-established
# practices/traditions
##

I believe the issue of vendoring to be central to the discussion of
what Debian is, and what its role should be. We are very lucky to have
proponents of both sides of this issue in the Committee, and I'll try
to keep my ideas as centered as possible (of course, disclaimer: I do
hold a position, I really do not like vendoring; we have the luck of
having Elana in the ctte, as she is a developer of the affected
package, and Sean, who is a Debian Policy editor).

Elana started off with a very important and true point:

Elana>
I think this bug was sort of inevitable. Debian policy cruft is
clashing with how people actually build and distribute software
these days. we have an appeal to override a maintainer on the
basis of "policy" and the "Debian way being superior" without any
real technical examination of the merits of "the Debian way"

We are quite far from 1996, yes, and many languages have for a long
time delivered their own packaging systems, "freeing" the users from
the need of installing a myriad of little packages, and "freeing" the
distribution caregivers (and I don't only mean the developers, but
also the ftp-masters) and infrastructure from carrying this myriad of
little packages.

Elana and Sean seem to share the thought that each language ecosystem
could work with somewhat different rules:

Sean>
It might be reasonable to vendor like mad for something written in
Go but not for something written in Haskell, say

Elana>
Debian policy is specifically built around the distribution and
execution of dynamically linked C/C++ applications and
libraries. distros in general were. but modern software above that
base does not necessarily operate under the same assumptions and
it is silly to apply policy that was designed for applications
that are dynamically linked against programs that are statically
linked and are impossible to dynamically link

Simon mentioned that "our identity should be about shipping
high-quality packages, whatever that means", and mentioning that "our
packaging policy is designed for medium-sized packages", refereed back
to the discussions had long time ago over tiny Javascript snippets
packaged as packages, back in the starting days of the nodejs growth.

# DFSG-freeness checking
##

Sean and I shared the concern that excessive vendoring (say, having
tens to hundreds of libraries shipped as part of a single package)
place a very heavy burden on our ftp-masters when checking
DFSG-freeness; coupling this with the rapid change rate that
"new-wave" software development usually has, if adding / dropping
dependencies from already packaged software is usual practice,
DFSG-checks would not just have to be made in NEW, but as a continuous
process. Far from sustainable, and impossible to do by our ftp-master
team practices.

# Security issues
###

The issue of security support was also mentioned: If many packages
start shipping tens or hundreds of vendored libraries, how can we
ensure security support? This has long been a pride point for Debian
and, in general, for the Linux distributions model. We package
independent libraries, dynamically link them, and security supports
"just happens" for the users. Now, what happens in languages as Go or
Rust, where linking is done statically? They would have to be at least
recompiled when any of their constitutive libraries is updated. But
what if the libraries are vendored-in? Security issues are prone to be
hidden from our sight.

I'm pasting here a bit of the discussion that happened later during
the meeting: having this discussion K8S-specific, Elana mentioned that
"that is a big part of the tension. sometimes, you have an upstream
where the authors are less resourced and responsive than the
downstream. this case is almost certainly the opposite".

At this point, we found some friction as to _what_ we are discussing
on: Is this bug specifically on Kubernetes, which should be taken as a
special case? Or would we try to rule as the Technical Committee on
vendoring in general in the Debian ecosystem? Elana repeated her
assurance that the Kubernetes team is thorough in their
freeness-checking and security practices; I insisted on "not
discussing about K8S, but about a bundling practice to which K8S