Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-24 Thread Sean Whitton
Hello Chris,

On Mon 24 Jan 2022 at 11:33AM +01, Chris Hofstaedtler wrote:

> For context, the idea is that /usr/bin/rename should become
> src:util-linux' rename implementation.

That seems likely to break a great many scripts, though?

Perhaps we should ship them both under a name other than
/usr/bin/rename, such that people are prompted to update their scripts
to choose one, or create their own symlink?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-23 Thread Sean Whitton
Hello Christoph,

On Sun 23 Jan 2022 at 10:27PM +01, Christoph Berg wrote:

> Re: Sean Whitton
>> Hello,
>>
>> On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:
>>
>> > I guess the best thing would be to introduce a new binary package,
>> > but I am out of ideas on naming it. Open for ideas here.
>>
>> util-linux-extra?
>
> If it's about rename only, "rename-ul" or even "rename.ul"?
>
> I guess it should also contain the historical name as a symlink.
>
> Christoph

Well, Chris mentioned wanting to transition some other things out of the
essential package in addition to this one.  Also, the ftp team would not
love the idea of a single-script package.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1003653: Revision of removal of rename.ul from package util-linux

2022-01-23 Thread Sean Whitton
Hello,

On Sun 23 Jan 2022 at 10:04PM +01, Chris Hofstaedtler wrote:

> I guess the best thing would be to introduce a new binary package,
> but I am out of ideas on naming it. Open for ideas here.

util-linux-extra?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne

2022-01-14 Thread Sean Whitton
On Fri 14 Jan 2022 at 11:55AM -07, Sean Whitton wrote:

> ===BEGIN
> The Technical Committee recommends that Helmut Grohne  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> H: Recommend to Appoint Helmut Grohne 
> F: Further Discussion
> ===END

I vote

H > F

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon

2022-01-14 Thread Sean Whitton
On Fri 14 Jan 2022 at 11:56AM -07, Sean Whitton wrote:

> ===BEGIN
> The Technical Committee recommends that Matthew Vernon  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> H: Recommend to Appoint Matthew Vernon 
> F: Further Discussion
> ===END

I vote

H > F

(Sorry for copy/pasting the wrong initial, Matthew!)

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1003738: tech-ctte: Call for votes on TC membership of Matthew Vernon

2022-01-14 Thread Sean Whitton
Package: tech-ctte
X-debbugs-cc: matt...@debian.org, lea...@debian.org

I call for votes on the following ballot to fill a vacant seat on the
Debian Technical Committee.  The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt.

===BEGIN
The Technical Committee recommends that Matthew Vernon  be
appointed by the Debian Project Leader to the Technical Committee.

H: Recommend to Appoint Matthew Vernon 
F: Further Discussion
===END

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#1003737: tech-ctte: Call for votes on TC membership of Helmut Grohne

2022-01-14 Thread Sean Whitton
Package: tech-ctte
X-debbugs-cc: hel...@subdivi.de, lea...@debian.org

I call for votes on the following ballot to fill a vacant seat on the
Debian Technical Committee.  The voting period starts immediately and
lasts for up to one week, or until the outcome is no longer in doubt.

===BEGIN
The Technical Committee recommends that Helmut Grohne  be
appointed by the Debian Project Leader to the Technical Committee.

H: Recommend to Appoint Helmut Grohne 
F: Further Discussion
===END

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Next Meeting -- January 14th at 1800 UTC

2022-01-13 Thread Sean Whitton
Hello,

On Mon 03 Jan 2022 at 10:52AM -07, Sean Whitton wrote:

> Our monthly meeting is scheduled for **Friday** 14th at **1800Z**.
>
> Agenda:
>
> * Review of previous meeting AIs
> * Recruitment
> * Any other business

Insert "Bug#1003653: Revision of removal of rename.ul from package
util-linux" after "Recruitment"..

> As we have only recruitment to discuss, let's do it entirely on Jitsi
> again.  We can use IRC just to track action items.

Let's switch over to IRC after "Recruitment".

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting -- January 14th at 1800 UTC

2022-01-03 Thread Sean Whitton
Hello,

Our monthly meeting is scheduled for **Friday** 14th at **1800Z**.

Agenda:

* Review of previous meeting AIs
* Recruitment
* Any other business

As we have only recruitment to discuss, let's do it entirely on Jitsi
again.  We can use IRC just to track action items.

The terms of Marga and David finished a few days ago -- many thanks
again.  According to convention I'm meant to resign as chair and call a
vote.  However, we are expecting to have two new appointments finished
by the end of the month, so unless there are objections, I'll follow the
other convention of resigning right after those people join, to avoid
two votes in quick succession.

-- 
Sean Whitton



January 2022 meeting poll

2021-12-08 Thread Sean Whitton
Hello,

As discussed at the meeting, could the six remaining members as of 1st
January kindly fill this in: <https://dudle.inf.tu-dresden.de/G-eGiXMZmQ/>

All times UTC.

We'll probably need to do this again once we fill the two empty seats,
hopefully for February's meeting.

-- 
Sean Whitton



Next Meeting -- 8th December at 7pm UTC

2021-12-06 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 7pm UTC.

Agenda:

* Review of previous meeting AIs
* Recruitment
* Any other business

As we have only recruitment to discuss, let's do it entirely on Jitsi?
We can use IRC just to track action items.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-11-12 Thread Sean Whitton
Hello Raphael,

On Tue 02 Nov 2021 at 08:31AM +01, Raphael Hertzog wrote:

> On Mon, 01 Nov 2021, Sean Whitton wrote:
>> Of course we should be exploring the new avenues that you mention.  But
>> becoming more willing to break unstable/testing than we are at present
>> might also be good for our project.
>
> Maybe, maybe not. What are you basing your assertion on?
>
> From my (limited) point of view, Debian testing/unstable is used by many
> derivatives because it's largely usable and stable, and we do get many
> contributions due to this.
>
> I for one contribute many fixes to Debian because Kali is built on Debian
> testing. At some point it was based on Debian stable and I was largely not
> able to contribute to Debian, and if we did break testing/unstable more
> often, the net result would likely that Kali would switch back to stable.
>
> I don't really see any scenario where breaking unstable/testing helps us
> in any way. Except if the breakage is really limited in time, and if the
> breakage does not affect upgrade paths, etc. But then I would no longer
> call that "breaking unstable/testing".

Thank you for bringing up derivatives, that's important.

The sort of situation I have in mind is where avoiding breaking unstable
results in a highly complex, drawn out and demotivating process, as
compared with just breaking unstable.  As we are mostly volunteers,
these sorts of considerations matter more than they might in other
organisations.  Thus, I am wary of categorically ruling out breaking
unstable as one of our options.

-- 
Sean Whitton


signature.asc
Description: PGP signature


New semi-formal ctte role: TC facilitators

2021-11-10 Thread Sean Whitton
Dear all,

I would like to draw your attention to the following text which we
recently committed to tech-ctte.git, in the context of our efforts to
get the TC involved earlier, when disputes are cooler.

[...]

Facilitators


Any developer or group of developers can request that the TC assign a
*facilitator* to work with them in the early stages of a technical
disagreement.

Facilitators are regular members of the TC that can provide
advice. Although this advice is not formally a statement of the TC, we
can expect the TC to defer to some degree to the views of one of their
members that has been deeply involved with the issue.

Facilitators are also DDs, so can carry out all of the normal activities
of a DD, including things like detailed design that are not possible for
the TC. Obviously the facilitator must be clear about when they are
acting as TC facilitator, and when they are acting as regular DDs. Some
facilitators may prefer to avoid any activities that would not be
permissible for the TC as a body.

As with any TC related activity, assigned facilitators may find
themselves in conflict of interest in a given disagreement. We trust
members of the TC to recognize such problems and, if it becomes
necessary, recuse themselves from their role as a facilitator, or even
recuse themselves from a later TC vote on the disagreement.

[...]

Contacting us
-

-   Formally, "requesting action from the TC" means "using
reportbug to contact us"
-   We want to streamline the process and hopefully avoid things
becoming TC bugs at all sometimes
-   Developers are welcome to contact the committee informally for
feedback, or to ask for a facilitator.
-   We can talk about your issue, even informally, via IRC
 `#debian-ctte` in OFTC
-   If you prefer, mail a brief summary
-   To our mailing list (public, archived: `debian-ctte@lists.debian.org`)
-   To our private alias (`debian-ctte-priv...@debian.org`)

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Next Meeting -- 14th October at 7pm UTC

2021-11-09 Thread Sean Whitton
Hello,

On Tue 09 Nov 2021 at 04:03PM -07, Sean Whitton wrote:

> Our monthly meeting is scheduled to take place Wednesday at 6pm UTC, but
> due to DST, ehashman can't attend unless we move it to 7pm.  Three other
> people say they prefer 7pm.  bremner won't join this time.  So unless
> both marga and ntyni say they can't do 6pm, let's meet at 7pm?

And let's do it via Jitsi, trying to keep minutes by typing things into
the IRC channel: <https://jitsi.debian.social/TechnicalCommittee>

Whoever joins the video chat first will be the admin.  Whoever that is,
please change the settings such that people have to be admitted one by
one, so we don't get invaded.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting -- 14th October at 7pm UTC

2021-11-09 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC, but
due to DST, ehashman can't attend unless we move it to 7pm.  Three other
people say they prefer 7pm.  bremner won't join this time.  So unless
both marga and ntyni say they can't do 6pm, let's meet at 7pm?

Apologies received from: bremner.

Agenda:

* Review of previous meeting AIs
* Recruitment
* Any others business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-10-13-17.59.html

People with AIs: spwhitton, marga, bremner

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-11-01 Thread Sean Whitton
Hello,

On Fri 29 Oct 2021 at 09:57AM +02, Raphael Hertzog wrote:

> I have sympathy with your reasoning and I can certainly relate to things
> that we did 20 years ago, where we happily broke unstable after a release
> but we have changed.
>
> Yes, on some aspects we have become more conservative. I certainly wish
> to change that, but not by going backwards, but by providing new avenues
> to experiment and make large-scale changes without breaking unstable/testing.

I'd like to express disagreement with the characterisation that breaking
unstable/testing more often for the sake of making major changes would
always count as going backwards.

Of course we should be exploring the new avenues that you mention.  But
becoming more willing to break unstable/testing than we are at present
might also be good for our project.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

2021-10-20 Thread Sean Whitton
On Wed 20 Oct 2021 at 12:30PM -07, Sean Whitton wrote:

> === Resolution A ===
>
> The Technical Committee resolves:
>
> 1. The debianutils package must continue to provide the which(1) program
>until a compatible utility is available in a package that is at least
>transitively essential in Debian 12.
>
>For the Debian 12 release, we expect which(1) to be in either an
>Essential package or a transitively Essential package (that is, a
>package that is depended on by an Essential package).
>
> 2. The which(1) program must not print any deprecation warnings.
>
> 3. We decline to overrule the maintainer of debianutils regarding the
>use of alternatives.  If another package takes over responsibility
>for which(1), then the debianutils maintainers and the other
>package's maintainers should coordinate to choose a suitable
>mechanism, which might be either versioned Depends/Breaks/Replaces,
>dpkg-divert, alternatives or something else.
>
> 4. The debianutils package must continue to provide the tempfile(1)
>program until a compatible utility is available in a package that is
>at least transitively essential in Debian 12.
>
>For the Debian 12 release, we expect tempfile(1) to be in either an
>Essential package or a transitively Essential package.
>
> 5. Programs in debianutils must not be moved to /usr until we have a
>project-wide consensus on going ahead with such a move, and any
>programs that have already been moved must be moved back.  In
>particular, this means debianutils must contain /bin/run-parts and
>/sbin/installkernel for the time being.
>
> === Resolution B ===
>
> As Resolution A, except strike point (2) and renumber succeeding items.
>
> === End Resolutions ===
>
> A: Issue Resolution A
> B: Issue Resolution B
> F: Further Discussion

I vote:

A > B > F

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Call for votes on "Reverting breaking changes in debianutils"

2021-10-20 Thread Sean Whitton
Hello,

I hereby call for votes on the following ballot to resolve #994275.  The
voting period starts immediately and lasts for up to one week, or until
the outcome is no longer in doubt (Constitution 6.3.1).

=== Resolution A ===

The Technical Committee resolves:

1. The debianutils package must continue to provide the which(1) program
   until a compatible utility is available in a package that is at least
   transitively essential in Debian 12.

   For the Debian 12 release, we expect which(1) to be in either an
   Essential package or a transitively Essential package (that is, a
   package that is depended on by an Essential package).

2. The which(1) program must not print any deprecation warnings.

3. We decline to overrule the maintainer of debianutils regarding the
   use of alternatives.  If another package takes over responsibility
   for which(1), then the debianutils maintainers and the other
   package's maintainers should coordinate to choose a suitable
   mechanism, which might be either versioned Depends/Breaks/Replaces,
   dpkg-divert, alternatives or something else.

4. The debianutils package must continue to provide the tempfile(1)
   program until a compatible utility is available in a package that is
   at least transitively essential in Debian 12.

   For the Debian 12 release, we expect tempfile(1) to be in either an
   Essential package or a transitively Essential package.

5. Programs in debianutils must not be moved to /usr until we have a
   project-wide consensus on going ahead with such a move, and any
   programs that have already been moved must be moved back.  In
   particular, this means debianutils must contain /bin/run-parts and
   /sbin/installkernel for the time being.

=== Resolution B ===

As Resolution A, except strike point (2) and renumber succeeding items.

=== End Resolutions ===

A: Issue Resolution A
B: Issue Resolution B
F: Further Discussion

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-10-18 Thread Sean Whitton
Hello,

On Sat 16 Oct 2021 at 05:50AM GMT, Clint Adams wrote:

> On Wed, Oct 13, 2021 at 01:05:50PM -0700, Sean Whitton wrote:
>>The debianutils package must continue to provide the tempfile(1)
>>program until a compatible utility is available in a package that is
>>at least transitively essential in Debian 12.
>
> Could you define "a compatible utility"?

I think it would be equivalent to the sense of compatibility that's
relevant when deciding whether two utilities can share a name managed by
the alternatives system?  So, a utility which behaves the same as
cjwatson-which when invoked in the ways in which cjwatson-which is
validly invoked, possibly with some additional command line switches and
the like.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Draft resolution for reverting changes in debianutils

2021-10-18 Thread Sean Whitton
Hello,

On Wed 13 Oct 2021 at 07:37PM -03, David Bremner wrote:

> Sean Whitton  writes:
>
>> 1. Offer advice:
>
>>The debianutils package must continue to provide the which(1) program
>>until a compatible utility is available in a package that is at least
>>transitively essential in Debian 12.
>
> Is it really advice if we say "must"?

The point here is just that the maintainer has not dropped which(1) so
it is not the case that we are overruling the maintainer, unlike in the
other points.  Perhaps we could label it as falling under 6.1.1 instead?
That's still distinct from 6.1.4.

>> 2. Overrule maintainer of debianutils:
>>
>>The which(1) program must not print any deprecation warnings.
>
> I remain to be convinced on this point.

Okay.  Procedurally, what I think we should do here is have two options
other than FD on the ballot, with and without this particular bit of the
resolution.

> If I understand the issue correctly the problem is with autopkgtests
> failing because they were not expecting output on stderr. I don't
> think people are really entitled to expect which(1) to never print to
> stderr. Even when debian-policy recommended 'which' it apparently
> recommended redirecting stderr.
>
> I also don't see failures of autopkgtests as directly impacting users in
> the same way a failure to build or a failure to install does.
>
> I understand that people find the message annoying, and perhaps not that
> useful, but I don't think that rises the level justifying overriding a
> maintainer.

As Raphael has mentioned, it's unlikely that when debianutils' which(1)
has been replaced with one in another essential or transitively
essential package that the new which(1), whether it's the same code or
something else, will print deprecation warnings.  And then it seems odd
to print them for a while and then stop printing them.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-18 Thread Sean Whitton
ing previous development cycles
> include the libglib-2.0.so.0 and libgcrypt.so.20 shared libraries,
> and the command-line utilities in the iptables package.
>
> The Technical Committee recommends that during the Debian 12 development
> cycle, the maintainers of individual packages should not proactively move
> files from the root filesystem to the corresponding locations in /usr in
> the data.tar.* of packages. Files that were in /usr in the Debian 11
> release should remain in /usr, while files that were in /bin, /lib* or
> /sbin in the Debian 11 release should remain in those directories.
> If files were moved from /bin, /lib* or /sbin into /usr since the
> Debian 11 release, they should be moved back to their Debian 11
> locations.
>
> Similarly, during the Debian 12 development cycle, we recommend that
> maintainers of tools such as debhelper should not move files from the
> root filesystem into /usr.
>
> For example, debhelper 13.4 started moving systemd units from /lib/systemd
> into /usr/lib/systemd, but this was subsequently reverted in 13.5.2. We
> consider the revert that was done in 13.5.2 to have been an appropriate
> course of action.
>
> We issue this recommendation for several reasons:
>
> - The transition to merged-/usr will make the logical locations of these
>   files irrelevant to their physical locations.
>
> - The transitional mechanisms necessary to prevent such moves from breaking
>   other packages that hard-code specific paths are error-prone, and can
>   themselves interfere with the transition to merged-/usr.
>
> - After the transition to merged-/usr has completed, during the Debian 13
>   development cycle, we expect that maintainers will be able to move these
>   files without needing transitional mechanisms.
>
> - On merged-/usr systems, there is a possible failure mode involving files
>   being moved between packages (with Replaces) during the same release
>   cycle that their logical location is changed from the root filesystem
>   to the corresponding aliased directory in /usr, which can result in
>   the affected file disappearing. This can be avoided by not changing
>   the file's logical location until the beginning of the Debian 13
>   development cycle, after the transition to merged-/usr is complete.
>
> - On non-merged-/usr systems, a failure mode has been observed in which
>   older shared libraries in /lib/MULTIARCH are not always deleted as
>   intended, and interfere with correct loading of the newer shared
>   library in /usr/lib/MULTIARCH. This can be avoided by not changing
>   the file's logical location until the beginning of the Debian 13
>   development cycle, after the transition to merged-/usr is complete,
>   at which point ldconfig(8) will choose the newer library even if
>   this occurs.
>
> This recommendation applies until Debian 12 is released, or until
> a subsequent Technical Committee resolution rescinds it, whichever
> is sooner. We intend to rescind this recommendation if mechanisms are
> developed to avoid the undesired side-effects of moving files from the
> root filesystem into /usr.
>
>  end text to be voted on 

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Draft resolution for reverting changes in debianutils

2021-10-13 Thread Sean Whitton
Dear all,

We think we might have a consensus on the following resolution text.  We
could be wrong, as the judgement of consensus has been made by just a
few of us.  We agreed in our meeting today that I'll start a vote a week
from today unless a ctte member asks for a delay.  Thus, we expect to
close this bug approximately two weeks from today.

Many thanks to Simon for a previous draft of this text.

~=~=~=~=~

1. Offer advice:

   The debianutils package must continue to provide the which(1) program
   until a compatible utility is available in a package that is at least
   transitively essential in Debian 12.

   For the Debian 12 release, we expect which(1) to be in either an
   Essential package or a transitively Essential package (that is, a
   package that is depended on by an Essential package).

2. Overrule maintainer of debianutils:

   The which(1) program must not print any deprecation warnings.

3. Decline to overrule maintainer regarding use of alternatives:

   If another package takes over responsibility for which(1), then the
   debianutils maintainers and the other package's maintainers should
   coordinate to choose a suitable mechanism, which might be either
   versioned Depends/Breaks/Replaces, dpkg-divert, alternatives or
   something else.

4. Overrule maintainer of debianutils:

   The debianutils package must continue to provide the tempfile(1)
   program until a compatible utility is available in a package that is
   at least transitively essential in Debian 12.

   For the Debian 12 release, we expect tempfile(1) to be in either an
   Essential package or a transitively Essential package.

5. Overrule maintainer of debianutils:

   Programs in debianutils must not be moved to /usr until we have a
   project-wide consensus on going ahead with such a move, and any
   programs that have already been moved must be moved back.  In
   particular, this means debianutils must contain /bin/run-parts and
   /sbin/installkernel for the time being.

~=~=~=~=~

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-13 Thread Sean Whitton
Hello Simon,

On Tue 05 Oct 2021 at 07:48PM +01, Simon McVittie wrote:

> On Sun, 03 Oct 2021 at 16:52:15 -0700, Sean Whitton wrote:
>> On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:
>> > On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
>> >> (1) The reason for this, to put it a bit simplistically, is that we
>> >> don't require apt to perform the upgrade between stable releases in any
>> >> particular order, right?  Or are there other reasons distinct from this
>> >> one that I'm missing?  I think it would be good to state the thing about
>> >> apt (in better language than mine) in the text.
>> >
>> > I think that's the main reason. We have not traditionally mandated
>> > the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
>> > so the upgrade happens in whatever order apt chooses, which can vary
>> > between machines.
>> >
>> > Another reason why I think we want Debian 12 packages to be installable
>> > onto non-merged-/usr systems is that to be able to do our development work,
>> > they need to be installable onto testing/unstable systems, which (again)
>> > means that the upgrade order is undefined.
>>
>> Right, we're on the same page then, but would you agree with me that the
>> resolution should state this justification explicitly?
>
> I hope that
> <https://salsa.debian.org/debian/tech-ctte/-/merge_requests/4>
> implements this to your satisfaction. If not, suggestions for better
> wording welcome - I would prefer not to be the only one writing this
> document!

Thanks, yes, this addresses my feedback.

I've pushed some wording tweaks.  Hope you don't mind me not filing a
MR -- seemed uncontroversial so thought I'd just push.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting -- 13th October at 6pm UTC

2021-10-13 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.  I
am unlikely to be able to look into Jitsi before then as I have a busy
start to the week.  Unless someone else would like to do that, let's IRC
this time.

Proposed agenda:

* Review of previous meeting AIs
* #994275 - Reverting breaking changes in debianutils
* #994388 - More specific advice regarding merged-/usr and implications of 
#978636
* Recruitment
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-09-08-17.59.html

People with AIs: bremner, marga, spwhitton, smcv

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting -- 13th October at 6pm UTC

2021-10-13 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.  I
am unlikely to be able to look into Jitsi before then as I have a busy
start to the week.  Unless someone else would like to do that, let's IRC
this time.

Proposed agenda:

* Review of previous meeting AIs
* #994275 - Reverting breaking changes in debianutils
* #994388 - More specific advice regarding merged-/usr and implications of 
#978636
* Recruitment
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-09-08-17.59.html

People with AIs: bremner, marga, spwhitton, smcv

-- 
Sean Whitton



Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-10-03 Thread Sean Whitton
Hello,

On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:

> On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
>> You write:
>>
>> >> - Because Debian 11 installations with the non-merged-/usr layout already
>> >>   exist, all packages in Debian 12 should be installable onto a 
>> >> non-merged-/usr
>> >>   system along with their dependencies, and work correctly on the 
>> >> resulting
>> >>   system.
>>
>> (1) The reason for this, to put it a bit simplistically, is that we
>> don't require apt to perform the upgrade between stable releases in any
>> particular order, right?  Or are there other reasons distinct from this
>> one that I'm missing?  I think it would be good to state the thing about
>> apt (in better language than mine) in the text.
>
> I think that's the main reason. We have not traditionally mandated
> the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
> so the upgrade happens in whatever order apt chooses, which can vary
> between machines.
>
> Another reason why I think we want Debian 12 packages to be installable
> onto non-merged-/usr systems is that to be able to do our development work,
> they need to be installable onto testing/unstable systems, which (again)
> means that the upgrade order is undefined.

Right, we're on the same page then, but would you agree with me that the
resolution should state this justification explicitly?

> We also have best-effort support for partial upgrades, either
> oldstable -> stable or stable -> testing/unstable: upgrading only a
> subset of the available packages, plus their mandatory dependencies,
> but without also upgrading apparently-unrelated packages. This can
> only ever be partially supported, because it leads to a combinatorial
> explosion of possible partially-upgraded systems, and realistically we
> can never test them all; but I think it's best if we try to avoid
> knowingly making this worse.

I'd suggest we don't mention this as it's much more obscure and the
above is sufficient justification.

>> (2) Some people on -devel would seem to think that we can have smooth
>> upgrades from bullseye to bookworm without requiring support for
>> non-merged-/usr in every single package in bookworm, i.e., without
>> supporting non-merged-/usr for testing/unstable installations during the
>> current release cycle.
>
> Some people on -devel have argued that it would be OK to require use of
> a special upgrade tool analogous to Ubuntu's do-release-upgrade just this
> once, or that it would be OK to require a particular upgrade sequence. For
> example, we could ask users to install the usrmerge package first, and
> then upgrade; or if dpkg is modified to special-case the merged-/usr
> aliasing symlinks, then we might ask users to upgrade dpkg first, and
> then upgrade the rest of the system.
>
> I think there is considerable anecdotal evidence that many Debian users
> do not read the release notes, and if we ask them to carry out an upgrade
> procedure more complicated than
>
> $editor /etc/apt/sources.list && apt update && apt full-upgrade
>
> they will often ignore that request and still expect their upgrade to
> work (because in practice it often does, and we've been training users
> to expect that for years). That makes me reluctant to require a special
> upgrade procedure if it is not strictly necessary.

This is persuasive.  What do you think about including it in the text?
Specifically, mentioning that we are deciding, for the project, that
we are not going to do this using something like do-release-upgrade(8).

>> What smcv has been arguing for is the most conservative option.  But
>> which of the following is it the TC wants to say:
>>
>> - we are sure that this is the only way to ensure smooth upgrades, such
>>   that it pretty much follows from our previous decision on merged-/usr
>>
>> - we think there might be viable alternatives to requiring every package
>>   in bookworm to work on both layouts, but we aren't sure they are safe
>>   enough, so we're recommending a simple and conservative approach
>>
>> - we think that ensuring non-merged-/usr testing/unstable installations
>>   work during this release cycle is reason enough to take this highly
>>   conservative approach
>
> I'm honestly not sure which of these is "the" reason why I'm recommending
> the conservative approach. Some combination of your second and third
> points, I suppose?

Based on what you say above I think it's the second and third, indeed.
If we add to the text the things I'm suggesting we add, I think this
sort of query about our motivations will not arise in the minds of
readers.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-09-24 Thread Sean Whitton
Hello Clint,

On Fri 24 Sep 2021 at 12:52PM GMT, Clint Adams wrote:

> What I want is for GNU which to stop languishing in NEW, for the dozen
> people who keep complaining that FreeBSD which is better and some other
> volunteer should package FreeBSD which to actually spend the 15 minutes
> to do the work of packaging it, and if anyone wants to retain what I'll
> call "cjwatson which", to package that separately as well.
>
> Any subset of the above allows me to stop shipping which.debianutils
> post-release, and hopefully not install any which-providing package on
> my system.

I thought what you wanted was to drop cjwatson-which, either in favour
of no which in Debian at all, or the option to install GNU or BSD which.

However, you have now suggested that someone could package
cjwatson-which in another package.  But in that case, what do you see
removing cjwatson-which from debianutils as achieving?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

2021-09-16 Thread Sean Whitton
 Implementing
>   merged-/usr as the only supported layout means that moving files into
>   /usr on an individual basis is mostly unnecessary, because it has no
>   practical effect any more.

The case you make for this is convincing, given everything else said.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-09-16 Thread Sean Whitton
Hello,

On Thu 16 Sep 2021 at 03:02PM -07, Sean Whitton wrote:

> The TC can't do detailed design work, so without such a proposal on the
> table, we're left deciding between a complete reversion and doing
> nothing at all.  It would be good to have more options.

This isn't quite right -- we could choose to implement some of your five
requests.  But this would not really yield an alternative transition
plan.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-09-16 Thread Sean Whitton
Hello Adrian,

On Wed 15 Sep 2021 at 01:36AM +03, Adrian Bunk wrote:

> Package: tech-ctte
> Severity: normal
>
> This is a request to override the maintainer of debianutils on several
> changes that were done to the package in unstable after the release of
> bullseye.
>
>
> More specifically, I am asking the Technical Committee to decide that:
>
> 1. The "which" program must be provided by an essential package.
>
> 2. The "which" program must not print any deprecation warnings.
>
> 3. The "which" program must not be provided through alternatives.
>
> 4. The debianutils package must continue to provide the "tempfile" program.
>
> 5. Programs in debianutils must not be moved to /usr unless there is
>project-wide consensus on packages doing such a move, and premature
>moving must be reverted.

Roughly speaking, you're asking for a complete reversion of the change.

Do you perhaps have a middle-ground proposal which would

(i) accept the decision of the debianutils maintainer that which should
be removed from the Essential set within a release cycle or so, but
also would

(ii) include a transition/deprecation plan which would impose less of a
 burden, from your point of view, on Debian contributors?

The TC can't do detailed design work, so without such a proposal on the
table, we're left deciding between a complete reversion and doing
nothing at all.  It would be good to have more options.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting -- 8th September at 6pm UTC

2021-09-05 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.
How about we try out concurrent Jitsi and IRC, typing enough into IRC
that we end up with decent minutes?  I've asked #debian-video if we can
use their infra, unless anyone else has a Jitsi server available?

Proposed agenda:

* Finalising private communication proposal
* Finalising early invocation proposal
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-08-11-18.00.html

-- 
Sean Whitton



The TC's DebConf21 session

2021-08-11 Thread Sean Whitton
Hello DebConf content team,

The TC discussed our DebConf21 session at our monthly meeting today.  We
would like to run our own Q, which we think will take up 20--25
minutes of our talk.

We were wondering whether the easiest way to arrange this would be for
one of us to talkmeister the session?  If you agree, can you let us know
the arrangements for talkmeister training this year?  We assigned me to
this task, and marga would like to get trained too as a backup.

Thank you!

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting -- 11th August at 6pm UTC

2021-08-08 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.

Proposed agenda:

* Review of previous meeting AIs
* Private communication presentation at DebConf
* Early invocation presentation at DebConf
* Timing issues of our presentation
  - how many minutes for beginning intro
  - equal time for two proposals?
  - separate Q after each proposal or all at end?
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-07-14-17.59.html

People with AIs: ehashman, gwolf, spwhitton

-- 
Sean Whitton



Next Meeting -- 14th July at 6pm UTC

2021-07-09 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.

Proposed agenda:

* Review of previous meeting AIs
* Private communication presentation at DebConf
* Early invocation presentation at DebConf
* DebConf session logistics
  - possibly doing a quick test group video call
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-06-09-18.00.html

People with AIs: ehashman, gwolf, spwhitton

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#990426: www.debian.org: Clarify status of list of old TC decisions

2021-06-28 Thread Sean Whitton
Package: www.debian.org
Tags: patch
X-debbugs-cc: debian-ctte@lists.debian.org

Dear webmasters,

At a recent TC meeting[1] it was noted that the list of decisions on the
TC page on the Debian website is quite out-of-date -- for example,
appointing new members is done using our official decision-making
process, but none of the decision processes leading to the appointments
of any of the sitting members of the committee are listed :)

Our view is that while the BTS records of discussions and decisions are
the source of truth, it is valuable to have the website page too, as
it's quite interesting for anyone interested in Debian history.  We also
thought that it is not a problem if it doesn't get kept up-to-date until
someone gets around to it.

However, we thought it would be best if some text on the page linked to
the BTS archives, and notes that the www page is often out-of-date.
There is some language to this effect already but it is only attached to
one section of the page and does not clearly state that the BTS is the
official record.  So I would like to propose the attached patch.

Thanks!

[1]  
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-05-12-18.00.log.html

-- 
Sean Whitton
From 4e667d4efa461770e83c842bcd737380616c934e Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Mon, 28 Jun 2021 13:53:39 -0700
Subject: [PATCH] Be explicit that source of truth for TC activities is the BTS

See minutes of TC meeting on 12th May 2021 for discussion:
<http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-05-12-18.00.log.html>
---
 english/devel/tech-ctte.wml | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/english/devel/tech-ctte.wml b/english/devel/tech-ctte.wml
index 6e672da1626..f619bcf3be6 100644
--- a/english/devel/tech-ctte.wml
+++ b/english/devel/tech-ctte.wml
@@ -100,8 +100,13 @@ Debian Organizational Structure page.
 The https://lists.debian.org/debian-ctte/;>committee mailing list
 is archived.
 
-https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tech-ctte;>Questions pending decision
-can be reviewed in the bug tracking system.
+The official record of both discussions and decisions is the bug tracking
+system: you can view https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tech-ctte;>questions
+pending decision and https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tech-ctte;archive=yes;>archived
+discussions and decisions.  The lists of decisions further down this page
+is often out-of-date and are maintained primarily for historical interest.
 
 VCS repository
 
@@ -112,11 +117,6 @@ for collaboration.
 
 Formal technical decisions, including recommendations and advice
 
- The decision history sections are not necessarily up to date.
-  (https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=tech-ctte;archive=yes;>Older
-  questions and decisions can be viewed in the bug tracking
-  system.)
-
 
   https://lists.debian.org/debian-devel-announce/2019/03/msg1.html;>2019-03-05
 https://bugs.debian.org/914897;>Bug #914897:The
@@ -293,8 +293,8 @@ inclusion of code to create isdn devices by isdnutils.
 Manoj; no-one else voted and Ian used his casting vote.
 
 
-NB that decisions from before the 1st of April 2002 are not yet
-recorded here.
+NB that no decisions from before the 1st of April 2002 are yet recorded
+here yet.
 
 Formal nontechnical and procedural decisions
 
@@ -337,8 +337,8 @@ recorded here.
 
 
 
-NB that decisions from before the 31st of January 2002 are not yet
-recorded here.
+NB that no decisions from before the 31st of January 2002 are recorded here
+yet.
 
 Retired members
 
-- 
2.30.2



signature.asc
Description: PGP signature


Next Meeting - 9th June at 6pm UTC

2021-06-07 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.

Our agenda:

* Review of previous meeting AIs
* Submitting this year's "Meet the Technical Committee"
* Moving forward with our reimagining the TC tasks
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-05-12-18.00.html

People with AIs: ehashman, marga

-- 
Sean Whitton


signature.asc
Description: PGP signature


Next Meeting - May 12th at 6pm UTC

2021-05-09 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.

Our agenda:

* Review of previous meeting AIs
* #976462 - Should dbgsym files be compressed via objcopy 
  --compress-debug-section or not?
* Moving forward with our reimagining the TC tasks
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-04-14-17.57.html

People with AIs: ehashman, marga, smcv

-- 
Sean Whitton



Next Meeting - April 14th at 6pm UTC

2021-04-10 Thread Sean Whitton
Dear Technical Committee members,

Our monthly meeting is scheduled to take place Wednesday at 6pm UTC.
Note that we've moved to meeting on second Wednesdays.

Our agenda:

* Review of previous meeting AIs
* #976462 - Should dbgsym files be compressed via objcopy 
  --compress-debug-section or not?
* Moving forward with our reimagining the TC tasks
* Any other business

Notes from the previous monthly meeting:
http://meetbot.debian.net/debian-ctte/2021/debian-ctte.2021-03-17-17.59.html

People with AIs: ehashman, marga, smcv

-- 
Sean Whitton



Bug#976462: debian bug 976462

2021-03-17 Thread Sean Whitton
Hello,

On Wed 10 Mar 2021 at 04:54PM +01, Mark Wielaard wrote:

> For reference, this is the dwz bug for [dwz] Support compressed debug
> sections: https://sourceware.org/bugzilla/show_bug.cgi?id=24725
>
> It has low priority because it has a simple workaround:
> you could use eu-elfcompress before/after the dwz run
>
> $ eu-elfcompress --type=none ./a.out
> $ dwz ./a.out
> $ eu-elfcompress --type=zlib ./a.out

Thanks for the input.  In any case in which the reason not to use
compressed debug symbols is something to do with package builds, a
workaround of this form could be used.

Then, the only tool compatibility reasons not to use compressed debug
symbols are (i) tools that users who have the symbols installed want to
run; and (ii) complicated debhelper order-of-operation issues which make
it difficult to use the above workaround.

Given that the debhelper maintainer said that he doesn't mind whether or
not compression is turned on, I think we can eliminate (ii).

Looking back through the thread, the closest thing we have to (i) is two
bugs in Valgrind.  However, those bugs are both marked as resolved.

So, I conclude that we still haven't seen concrete tooling problems
which would give us good reasons to disable compression.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#985270: Resignation + Call for votes for new Chair

2021-03-15 Thread Sean Whitton
Resending signed.

On Mon 15 Mar 2021 at 08:46AM -07, Sean Whitton wrote:

> On Mon 15 Mar 2021 at 10:30AM +01, Margarita Manterola wrote:
>
>> ===BEGIN===
>>
>> The chair of the Debian Technical Committee will be:
>>
>>  A : Margarita Manterola
>>  B : David Bremner
>>  C : Niko Tyni
>>  D : Gunnar Wolf
>>  E : Simon McVittie
>>  F : Sean Whitton
>>  G : Elana Hashman
>>  H : Christoph Berg
>>
>> ===END===
>
> I vote:
>
> A = B = C = E = F = G > D > H
>
> I'd like to express my willingness to take this on if Marga has had enough.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#985270: Resignation + Call for votes for new Chair

2021-03-15 Thread Sean Whitton
On Mon 15 Mar 2021 at 10:30AM +01, Margarita Manterola wrote:

> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
>  A : Margarita Manterola
>  B : David Bremner
>  C : Niko Tyni
>  D : Gunnar Wolf
>  E : Simon McVittie
>  F : Sean Whitton
>  G : Elana Hashman
>  H : Christoph Berg
>
> ===END===

I vote:

A = B = C = E = F = G > D > H

I'd like to express my willingness to take this on if Marga has had enough.

-- 
Sean Whitton



Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2021-03-07 Thread Sean Whitton
Hello,

On Sun 07 Mar 2021 at 03:50PM -07, Sean Whitton wrote:

> This is not much good if your network is weak or you're offline, or you
> don't want information on your debugging to go out to a web service.

What I mean is: debuginfod is great in many scenarios, but we should
probably care about those who can't or won't use it too.  Sorry if the
above is a bit blunt.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2021-03-07 Thread Sean Whitton
Hello,

On Fri 05 Mar 2021 at 06:22PM +01, Matthias Klose wrote:

> yes, the rationale for uncompressed debug sections is that any tool can access
> them.  On disk as deb/dbgsym package, there is no big difference in
> size.

The data elsewhere in this bug would suggest otherwise!

> Also a debuginfod server can be configured to send the debuginfo
> compressed on the fly.  The "only" downside is to have the uncomressed
> debuginfo on the disk when doing the debugging.

This is not much good if your network is weak or you're offline, or you
don't want information on your debugging to go out to a web service.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2021-03-07 Thread Sean Whitton
Hello Josh,

On Sat 06 Mar 2021 at 12:32PM -08, Josh Triplett wrote:

> Jakub Wilk wrote:
>> A few months ago I recompressed whole buster/main/amd64 to see what the 
>> effect of ditching --compress-debug-sections would be.
>>
>> Raw data for this experiment is available here:
>> https://github.com/jwilk/lets-shrink-dbgsym/releases/download/20200708/buster-main-amd64-20200708.tsv.xz
>
> Thanks for collecting this data.
>
> Based on this, I computed the top 50 packages by installed-size
> increase, and the corresponding percentage increase:

Do you think you could do some grouping -- e.g. put all the kde packages
together and see what that comes to?  A lot of debugging scenarios are
going to involve groups of packages like these.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#982987: tech-ctte: Call for votes for new CTTE member

2021-02-17 Thread Sean Whitton
Hello,

On Wed 17 Feb 2021 at 12:45PM -06, Gunnar Wolf wrote:

> ===BEGIN
>
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
>
> ===END

I vote

A > B

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#976462: Bug#631985: Compress debug

2021-02-07 Thread Sean Whitton
Hello,

On Thu 04 Feb 2021 at 03:20PM -08, Josh Triplett wrote:

> On Mon, 25 Jan 2021 12:01:02 -0700 Sean Whitton  
> wrote:
>> On Mon 07 Nov 2011 at 06:34PM +01, Bastien ROUCARIES wrote:
>> > I agree it could be done by default with compat 9. Will decrease the
>> > size of archive also. I need more than 10G in order to debug kde...
>>
>> Does this sort of thing still apply in 2021?
>
> Yes.
>
> Apart from the running joke that the persistent state of most disks is
> "full", this remains relevant because it can make the difference between
> "leave the debug symbols installed, keep them updated, and be able to
> debug quickly the next time" versus "install debug symbols, debug,
> remove debug symbols until they're next needed".

So, just to confirm, you're saying that you think that you or people you
know would end up doing the latter pretty regularly if we were to decide
to turn off compression?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#976462: Bug#631985: Compress debug

2021-01-25 Thread Sean Whitton
Hello Bastien,

On Mon 07 Nov 2011 at 06:34PM +01, Bastien ROUCARIES wrote:

> I agree it could be done by default with compat 9. Will decrease the
> size of archive also. I need more than 10G in order to debug kde...

Does this sort of thing still apply in 2021?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#978636: move to merged-usr-only?

2021-01-25 Thread Sean Whitton
Dear Technical Committee members,

I call for votes on the following ballot to resolve #978636.  The voting
period starts immediately and lasts for up to one week, or until the
outcome is no longer in doubt (§6.3.1).

===BEGIN
The Technical Committee resolves that Debian 'bookworm' should support
only the merged-usr root filesystem layout, dropping support for the
non-merged-usr layout.

Until after the release of 'bullseye', any implementation of this
resolution must be done in the 'experimental' distribution, or otherwise
kept out of the critical paths for the release of 'bullseye'.

We do not recommend any particular implementation of the migration.

Y: Yes, support only merged-usr in the 'bookworm' release.
N: No, continue to support both layouts in 'bookworm'.
F: Further Discussion
===END

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#978636: move to merged-usr-only?

2021-01-25 Thread Sean Whitton
Hello,

On Mon 25 Jan 2021 at 11:45AM -07, Sean Whitton wrote:

> I call for votes on the following ballot to resolve #978636.  The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
>
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
>
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
>
> We do not recommend any particular implementation of the migration.
>
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

I vote:

  Y > F > N

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

2021-01-12 Thread Sean Whitton
Hello,

On Tue 12 Jan 2021 at 01:53PM +02, Wouter Verhelst wrote:

> Maybe talk to debian-policy to come up with some wording to be added to
> either the developer's reference or policy that discourages dropping
> init scripts, but encourages talking to the maintainers of
> orphan-sysvinit-scripts if for whatever reason it ends up being
> necessary?

Once the package has cleared NEW, we should definitely mention it in
Policy; whether we say anything to discourage dropping init scripts is
trickier however.

-- 
Sean Whitton


signature.asc
Description: PGP signature


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

2020-12-28 Thread Sean Whitton
Hello,

On Mon 28 Dec 2020 at 12:24AM +01, gregor herrmann wrote:

> On Sun, 27 Dec 2020 15:39:47 -0700, Sean Whitton wrote:
>
>> On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:
>> > My reasoning is that init scripts are the end goal, and that elogind is
>> > just a symptom of that end goal, and that therefore talking about
>> > elogind in isolation serves no purpose.
>> The GR specifically mentions elogind and not init scripts.
>
> "Technologies /such as/ elogind …" (emph. mine) shows to me that this
> is meant as an example, as a "demonstration", and not as an
> exhaustive list [0]. So neither is elogind "special" nor is it the
> only relevant piece of software to consider supporting. [1]

Yes, fair enough, thanks.

I think what is more relevant is that hard Depends: are harder to work
around than being asked to move files between coinstallable packages.

-- 
Sean Whitton


signature.asc
Description: PGP signature


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

2020-12-27 Thread Sean Whitton
Hello Wouter,

On Sun 27 Dec 2020 at 07:26PM +02, Wouter Verhelst wrote:

> My reasoning is that init scripts are the end goal, and that elogind is
> just a symptom of that end goal, and that therefore talking about
> elogind in isolation serves no purpose.

The GR specifically mentions elogind and not init scripts.

-- 
Sean Whitton


signature.asc
Description: PGP signature


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

2020-12-15 Thread Sean Whitton
Hello,

On Tue 15 Dec 2020 at 11:14AM GMT, Mark Hindley wrote:

> Sean and Simon,
>
> On Mon, Dec 14, 2020 at 01:17:30PM -0700, Sean Whitton wrote:
>> > In the cases where the regression was accidental, ideally, the answer
>> > would be someone calmly and politely offering a tested patch, but it
>> > sadly seems equally likely to result in hostility, and I think it's
>> > reasonable for a maintainer to try to avoid that preemptively by making
>> > it clear that the LSB init script is someone else's responsibility.
>> > Our volunteers are not automata, and I think maintainers need to be able
>> > to set boundaries for their responsibilities to protect their mental state.
>> >
>> > Similarly, in the case where the dependency is deliberate, I don't
>> > think we want the responsibilities of a Debian maintainer to include
>> > interceding between angry sysvinit users and upstream.
>>
>> Okay, great, I now see a clearer argument in favour of dropping the init
>> script: enabling the maintainer to preemptively avoid dealing with bugs
>> which are likely to generate hostility, rather than just the idea that
>> there could be bugs which would generate a lot of technical work for the
>> maintainer in which the maintainer does not see much value.
>
> I am afraid I don't agree with this.
>
> Hostility is never justified or justifiable and none of us should ever have 
> to be
> subject to it or tolerate it.  However, using the avoidance of putative poor
> behaviour by others in the future as a justification for a current or past 
> action
> seems a weak argument to me. IMO, the best way to promote the ideals of
> tolerance, courtesy, humility and openness is by espousing them in one's 
> actions
> and by doing the right thing.

It would not be good to assume that there are never circumstances in
which preemptively avoiding hostility by refusing to engage with certain
technical options is a reasonable thing for a maintainer to do, but
whether it is something the project can accept in this particular case
is still in question.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

2020-12-14 Thread Sean Whitton
Hello Niels,

On Sat 05 Dec 2020 at 01:12PM +01, Niels Thykier wrote:

> The underlying arguments for and against --compress-debug-section appear
>  to be "download size" vs. "installed disk usage" vs. "Tooling support".
>  Though I ask you to please read the bugs #631985 and #922744 for the
> details of the arguments by both proponents.

Just had a look a these, thank you.

ISTM that the arguments in favour of compressing are more concrete right
now: in #631985 there is the example of debugging KDE requiring more
than 10G of disc space.  (Nine years later perhaps it is more.)  On the
other hand, in #922744, there is only an unsubstantiated reference to
tooling support.

I'm going to write to the submitter of #922744 asking for more info.

> Why punt it to you?
> ===
>
> [...]

I think the reasons you give are all reasonable.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#975381: Subject: libinih: drop Debian's custom vendorisation

2020-12-14 Thread Sean Whitton
control: tag -1 + moreinfo

Dear Stephan,

On Sat 21 Nov 2020 at 12:20PM GMT, Stephan Lachnit wrote:

> Currently the package libinih uses some heavy patches, which aren't upstream
> and aren't used by any other distro. I'm in favor of dropping this, but the
> current maintainer disagrees and we weren't able to make any progess in the
> discussion, so I want to put this here. Parts of the discussion can be found 
> on
> this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2
>
> To understand this, one has to look a bit at the history behind inih. Upstream
> was designed as a static library for embedded devices, and therefore has a lot
> of compile time options. At this point, the current maintainer created a patch
> to make all compile time option available on runtime.
>
> When gamemode started using inih, I wanted to get rid of shipped inih code and
> upstreamed a build system to inih for a shared library, that any distro can
> use. This was done in version 48. Due to the popularity of gamemode, inih is
> now found in most major distros (all without Debian's patches):
> https://repology.org/project/inih/versions
>
> There is a notable "exception": inih is not in Ubuntu's main repository. This
> is a bit weird because gamemode is in main, but with the shipped inih source
> which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm
> not sure why, but I suspect the heavy patches make it harder to be included in
> main.
>
> Because the library was designed for embedded use cases where every little bit
> of performance matters, the runtime patch was refused upstream. Dropping the
> runtime patch from Debian actually isn't problem, no reverse dependency of
> libinih uses compile time options anyway. However, due to the history of inih
> in Debian is has the soversion 1, while upstream is soversion 0.
>
> I want to drop the vendorisation of Debian and start a transition to soversion
> 0 (which is also a reason I contact the Technical Committee, as it's not clear
> how this would be done). A transition is needed anyway since dropping the 
> patch
> is a breaking change anyway. If the Technical Committee agrees to this, I 
> would
> also gladly help to maintain this package since it is 2 version behind 
> upstream
> since almost half a year and I maintain gamemode, which is directly affected 
> by
> this.

Your message it not clear enough for TC members not familiar with the
packages in question to understand what the dispute is.  We cannot wade
through discussions on salsa -- we need a summary.

Please make another attempt at summarising the dispute.  Please also
indicate which of the TC's powers (as granted by the constitution) you
are asking us to make use of.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature


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

2020-12-14 Thread Sean Whitton
Hello,

On Mon 14 Dec 2020 at 10:58AM GMT, Simon McVittie wrote:

> On Sun, 13 Dec 2020 at 14:38:24 -0700, Sean Whitton wrote:
>
>> Participants in the thread who have argued on that side of the
>> discussion seem to implicitly rely on the idea that a package maintainer
>> is responsible for applying an equally high level of quality assurance
>> to every file or feature in their package, as that which they would
>> apply to its most basic or flagship features.
>
> Ordinarily, perhaps yes. However, for whatever reason, people are
> particularly emotionally attached to particular init systems (or perhaps
> to the absence of systemd). We can see this here already: I don't think a
> dependency on a particular httpd or email server would have been brought
> to the technical committee asking for a maintainer to be overruled,
> and it seems unlikely to have had participants describing a maintainer
> declining an NMU as an outrage.
>
> If NM's LSB init script was present, but stopped working - perhaps
> because upstream deliberately made more use of systemd facilities, or
> because upstream accidentally relied on systemd facilities due to none of
> the upstream developers using anything else, or because the command-line
> syntax changed and the upstream-provided systemd unit was updated but the
> downstream init script wasn't - what do we expect to happen?
>
> In the cases where the regression was accidental, ideally, the answer
> would be someone calmly and politely offering a tested patch, but it
> sadly seems equally likely to result in hostility, and I think it's
> reasonable for a maintainer to try to avoid that preemptively by making
> it clear that the LSB init script is someone else's responsibility.
> Our volunteers are not automata, and I think maintainers need to be able
> to set boundaries for their responsibilities to protect their mental state.
>
> Similarly, in the case where the dependency is deliberate, I don't
> think we want the responsibilities of a Debian maintainer to include
> interceding between angry sysvinit users and upstream.

Okay, great, I now see a clearer argument in favour of dropping the init
script: enabling the maintainer to preemptively avoid dealing with bugs
which are likely to generate hostility, rather than just the idea that
there could be bugs which would generate a lot of technical work for the
maintainer in which the maintainer does not see much value.

It is difficult to think further about this without input from the
maintainer as to how much this was a part of his motivation, and what
experiences he has had led him to think in that way.

>> We want maintainers to
>> perform testing which is adequate to ensure that the core features of a
>> package won't regress if they upload a new version, but we do not take
>> maintainers to be responsible for testing every optional feature and we
>> accept that such things might be temporarily broken until someone other
>> than the maintainer can provide a patch.
>
> I think perhaps you have higher expectations of bug reporters than I do
> - perhaps because I'm involved in triaging/maintenance for user-facing
> desktop packages. Bug reports are not always accompanied by patches,
> and somewhat frequently come with the implication (or even an explicit
> demand) that the maintainer must stop whatever it is they are doing and
> fix the bug immediately.

Let me clarify the things I've said about the expectations we have of
maintainers on this point.  I don't think we do or should expect
anything at all of maintainers with regard to bugs that do not come with
patches, or that come with patches for which there is little indication
that much thought or testing has gone into them.

> In the case of init system integration, it isn't completely clear what
> the severity of "NM doesn't work with sysvinit" would be, and proponents
> of sysvinit might argue for critical because losing network connectivity
> effectively breaks the whole system in some cases, or serious because
> the package should be able to work without its non-mandatory dependencies.
> RC bugs are one of the few places where the project puts specific
> expectations on maintainers.
>
> Conversely, there's also a reasonable argument for important, normal
> or wishlist, because sysvinit is one of multiple options - but getting
> into an argument over bug severity is still getting into an argument,
> and for developers who don't enjoy conflict, takes significant "spoons"
> to deal with.

Good point.  Poor quality bug reports can be pretty easily ignored, but
we don't have a comparable approach for maintainers to take with regard
to severity wars.

>> We do not expect maintainers to maintain
>> an environment to test their package on 

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

2020-12-13 Thread Sean Whitton
Hello Simon and others,

On Sun 29 Nov 2020 at 06:13PM GMT, Simon McVittie wrote:

> If we are unable to use particular system services (in this case NM) with
> a particular non-default init system without putting extra responsibility
> on the maintainers of those system services, then I think that's a
> limitation of that init system that its maintainers could usefully
> address, and addressing that limitation would certainly be within the
> scope of exploring alternatives to systemd.

This is a good way to understand the notion of "exploring alternatives
to" systemd.  Thank you for explaining it.

I have not yet seen an argument which convinced me that asking the NM
maintainer to keep the init script in the package would actually be
putting extra responsibility on that maintainer, and this concerns me.

Participants in the thread who have argued on that side of the
discussion seem to implicitly rely on the idea that a package maintainer
is responsible for applying an equally high level of quality assurance
to every file or feature in their package, as that which they would
apply to its most basic or flagship features.  For example, it's been
suggested that requiring the NM maintainer to keep the file in the
package would mean that the NM maintainer would need to keep a sysvinit
system around to test that the init script still works before they could
upload a new version of NM.  I don't see why there would be any such
need.

Indeed, I don't think this is how we typically think of the
responsibilities of Debian package maintainers.  We want maintainers to
perform testing which is adequate to ensure that the core features of a
package won't regress if they upload a new version, but we do not take
maintainers to be responsible for testing every optional feature and we
accept that such things might be temporarily broken until someone other
than the maintainer can provide a patch.

In this case, I don't see how keeping the init script in the package
creates any expectations on the NM maintainer beyond applying patches to
the init script from those who have the relevant specialised knowledge.
A good analogy would be ports.  We do not expect maintainers to maintain
an environment to test their package on ports architectures before
uploading, but we do expect them to apply patches provided by porters
who discover regressions.  Why would our expectations be any greater in
this case?

Of course, if the script became seriously broken and was getting in the
way of a release or something like that, we would typically see it as
within the maintainer's prerogative to remove it.  Just as we would
accept a maintainer breaking compatibility with a port by reverting a
porter's patch if that was the only feasible way to meet a freeze
deadline, say.  But as has been pointed out, that's not the case we are
dealing with here.

I would like to see arguments that we would be imposing any extra
responsibility on the NM maintainer which do not rely on the idea that a
package maintainer is equally responsible for regressions anywhere in
their package, or, of course, an argument that I'm misunderstanding
what's being implicitly assumed.

The dependency issue is more challenging.

-- 
Sean Whitton


signature.asc
Description: PGP signature


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

2020-11-19 Thread Sean Whitton
Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> 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.

I have been thinking about this procedural issue and in the end I think
that it is moot.  Let me explain how things seem to me.

In our dispute resolution role, the TC is empowered to decide upon the
two things about the contents of the network-manager package that we
have been asked to decide upon, as a matter of last resort.  No-one
disputes that we can do this.

We have also been invited to rule that "Similar init-compatibility
changes should not be blocked by package maintainers unless they are
defective on their own merits".  Essentially we are being invited to
generalise the decision that we make about the network-manager package
to say that it would apply to similar cases.

We might decide that the reasons we have for whatever decision we make
about the network-manager package do not generalise, and so we may
decline the invitation to make any more general ruling.

But if we do think the reasons generalise, then we can generalise our
ruling without stepping outside of our dispute resolution role.  For
example, we might say "if another CTTE bug was filed about the contents
of a package which was similar to this one in the following respects
... then we would expect to issue the same ruling as we have here,
because we believe that our reasons for this ruling would apply to all
packages which are similar in the previously stated respects."

Clearly we would not want to say anything which we thought contravened
the GR.  However, I do not think there is any reason to think that
resolving this dispute would necessarily involve the TC interacting with
the GR in a way that the constitution does not permit.  We are being
asked to decide about one package, and being invited to generalise in a
way that falls within the scope of our dispute resolution role.

-- 
Sean Whitton



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

2020-11-19 Thread Sean Whitton
Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton


signature.asc
Description: PGP signature


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

2020-11-19 Thread Sean Whitton
Hello,

On Wed 18 Nov 2020 at 11:18PM -08, Josh Triplett wrote:

> I'd also like to address one other issue here. It would be easy to
> hypothesize, at this point, that some additional communication (or more
> verbose communication) from the maintainer might have helped here.
> However, I would express doubt that any more verbose version of "no"
> (e.g. a long-form explanation about undesired additional maintenance
> burden) would have led to any less escalation. I think the situation
> would still have ended up here, no matter how much time or energy was
> expended in writing responses.
>
> That seems particularly likely given the adversarial NMU directly
> attempting to override an active package maintainer's decision, which
> escalated the situation further. (Such adversarial NMUs have occurred in
> regard to alternative init support in the past, as well.) And I don't
> think anyone can reasonably suggest that they thought the change was
> made unintentionally (given that it was explicitly mentioned in the
> changelog), which makes the NMU a rather hostile escalation.
>
> I would ask anyone on the TC who feels that more verbose answers were
> desirable whether they think a more verbose answer would have had any
> effect on the outcome or subsequent escalations.

Assuming for a moment that the TC does not decline to rule, it is going
to be very hard for us to make a good decision if we lack more detailed
input from the package maintainer.

We can speculate as to whether the dispute would have proceeded better
or worse with more verbose messages from Michael before now, but it
would be beside the point.

-- 
Sean Whitton



Today's meeting

2020-11-18 Thread Sean Whitton
Hello,

Just to note that we had a meeting today:

http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-11-18-17.58.html

-- 
Sean Whitton


signature.asc
Description: PGP signature


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#947847: Fwd: Bug#946456: systemd: Provide systemd-sysusers as an independent package

2020-11-07 Thread Sean Whitton
Hello Michael,

On Wed 07 Oct 2020 at 09:53PM +02, Michael Biebl wrote:

> A small update here:
> v246 provides a build switch -Dstandalone-binaries=true:
> `
> option('standalone-binaries', type : 'boolean', value : 'false',
>description : 'also build standalone versions of supported binaries')
> `
>
> Atm, those supported binaries are systemd-tmpfiles and systemd-sysusers.
> Those binaries do not link against libsystemd-shared and have minimal
> dependencies.
>
> Fedora decided to ship those binaries in separate binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles, which
> conflict with the main systemd package, i.e. the main systemd package
> will continue to ship systemd-tmpfiles and systemd-sysusers linking
> against libsystemd-shared.
>
> I like this approach and think we should do the same in Debian.
> Users, which have the full systemd package installed don't have any
> negative side effects, which could result from splitting out
> systemd-tmpfiles/systemd-sysusers and libsystemd-shared.
>
> Restricted/non-systemd environments, like containers, can use
> systemd-standalone-sysusers and systemd-standalone-tmpfiles with minimal
> dependencies.
>
> We could debate whether systemd-standalone-tmpfiles and
> systemd-standalone-sysusers should be provided by a single binary
> package, but since Fedora has already done this split this way, I would
> simply follow here and use the same binary package names.
> The relevant Fedora PR is
> https://src.fedoraproject.org/rpms/systemd/pull-request/27 fwiw.
>
> Thankfully, -Dstandalone-binaries=true doesn't require a separate, third
> build variant (as with the udeb flavour), so build times shouldn't go up.
>
> If there are no objections to this approach I would proceed and
> implement it like this:
> - Build systemd with -Dstandalone-binaries=true
> - Install the standalone binaries in binary packages named
> systemd-standalone-sysusers and systemd-standalone-tmpfiles
> - Those binaries packages would only ship /bin/systemd-sysusers resp.
> /bin/systemd-tmpfiles and have a Conflicts/Replaces: systemd

From an ftpteam perspective it would probably be preferable to have a
single systemd-standalone binary package which could, if you wanted,
have Provides: systemd-standalone-sysusers and systemd-standalone-tmpfiles.

Otherwise, LGTM.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#971515: Request for security team input on kubernetes TC bug

2020-10-21 Thread Sean Whitton
Hello security team,

The TC are being asked about src:kubernetes, and it would be good to
hear from you about whether and how security support is a relevant
consideration in determining whether the level of vendoring in that
package is acceptable.  Could you take a look at #971515 and perhaps
give us some input, please?

Thanks.

-- 
Sean Whitton



Bug#971515: kubernetes: excessive vendoring (private libraries)

2020-10-21 Thread Sean Whitton
Hello Dmitry,

On Wed 21 Oct 2020 at 11:21am +11, Dmitry Smirnov wrote:

> On Wednesday, 21 October 2020 6:16:03 AM AEDT Sean Whitton wrote:
>> I think that my message [1] is what makes you think that the package
>> would not have got through NEW?
>
> It was not your message but my own experience with introducing of 100+ 
> packages through NEW, especially those ones with large burden of vendored 
> libraries, including Kubernetes. The main hassle usually is to convince FTP-
> masters when some vendoring is _necessary_ (case by case) and the usual 
> request is to package all vendored libraries separately. With rare exceptions 
> some (few) vendored libraries are allowed like when a library is a fork, 
> customised for the particular project and therefore not re-usable by other 
> software. Another example is when vendored library is an obsolete software 
> phasing out in future releases. Few micro-libraries might be tolerated when 
> vendored, especially when they are not widely used. Also vendoring might be 
> acceptable when software components with mutual/circular dependencies are 
> shipped in one or several name spaces - in other words when a software code 
> base is not from one name space but from several. None of those cases applies 
> to Kubernetes.
>
> A specific example (libpod/podman) is mentioned in 
>
>   https://lists.debian.org/debian-devel/2020/03/msg00441.html
>
> "Podman was rejected due to "many embedded packages in vendor/" with only
>  6 or 7 private libs versus 120 libraries removed in favour of packaged
>  ones."

Fair enough, but again, this is about NEW as a review by experienced
packagers rather than NEW as a blocker for inclusion.

> If your concern is about security support then IMHO Kubernetes can not be 
> meaningfully supported from security prospective, with or without vendored 
> dependencies.

Fair enough.  In the -devel thread the security team indicated that they
thought they could do security support in the case where there is
vendoring.  It would be good to get more input from them in this bug.

> If Debian only cared about maintainers' convenience or reducing maintainers 
> efforts then Debian would not be what it is now. We favour technical elegance 
> often in expense of maintainers' comfort.

I don't think maintainers' comfort is part of Janos' motivation -- it's
the issue of not having recent Kubernetes in Debian at all.

>> Are there issues the TC should think about which do not fall under this
>> way of looking at things?  I.e., weighing the impact on people other
>> than Janos who want to work on the package, vs. the impact on people who
>> want recent kubernetes to be part in the archive at all?
>
> Is Debian ecosystem of packaged reusable libraries worth caring about?
>
> If so then why grant exception to one particular package? We have several (or 
> more) sophisticated Golang packages using hundreds of packaged libraries.
>
> In the early days of packaging Kubernetes we did not even have most 
> components packaged and I've been spending most effort on packaging, 
> introducing and stabilising dependency libraries.
> These days the major work has already been done and the argument for 
> monolithic vendoring is much weaker.
>
> [...]

I think that we can all agree with everything you've written about the
reasons why packaging components separately is better.  The problem is
that in this case the choice seems to be between not having recent
Kubernetes in Debian at all, or giving up on some of those advantages.

-- 
Sean Whitton



Re: Bug#971515: kubernetes: excessive vendoring (private libraries)

2020-10-21 Thread Sean Whitton
Hello,

On Tue 20 Oct 2020 at 06:52pm -07, Felix Lechner wrote:

>  I think our response to the vendoring explosion is at odds with the
> trends in many languages.
>
> It's time to retool. At the two ends of the solution spectrum, I see
>
> 1. Fully vendored source packages; or
> 2. A packaging system that allows different vendor versions to co-exist.
>
> Either one allows dependent sources to consume whichever versions they
> require, but in my view solution (2) is otherwise superior---provided
> that the packaging process is automated. (A language's build system
> also has to distinguish the installed versions.) For each language so
> affected, could we make (2) our goal, and allow (1) until then?

This is a very general (but of course interesting) topic.  Could I ask
that it be kept out of this TC bug, please?  We have to figure out what
to do about this package given our present tooling.

-- 
Sean Whitton



Bug#971515: kubernetes: excessive vendoring (private libraries)

2020-10-20 Thread Sean Whitton
e Debian better and more useful, so perhaps we can focus on that
point of commonality.

[1]  https://lists.debian.org/debian-devel/2020/03/msg00363.html

-- 
Sean Whitton



Collating responses to our request for input

2020-08-19 Thread Sean Whitton
Dear all,

We said we'd work together to collate responses to our request for input
in advance of our BoF and I was meant to get that activity started ten
days ago, but I failed to do this.  I'm sorry about this -- I've been on
a sort-of vacation and haven't been looking at my scheduled tasks in the
way I normally would.

I have, however, been gathering message-ids of feedback we received, and
this morning I've gone through these and extracted those which I think
are broadly in line with our interests and intentions for this reform
project, such that we should try to incorporate them into our plan for
the talk.

I've extracted a few bullet points from each item to make it easier to
slot these into a talk plan, but we'd want to reread the actual mail
when doing that, rather than relying on my bullet points.

id:20200727014620.ko33taa3rwp3o...@qor.donarmstrong.com

  - still no design work, but ideas and working groups

  - issue opinions on parameters an ideal solution would have then
endorse the design

id:20200727182330.ga21...@layer-acht.org

  - we should carefully explain the "no design work" thing to avoid
misunderstanding and sidetracking (incorporate Marga's reply to
Holger's message)

id:36079a44-9b0e-4836-97f1-6154b830a...@beckenbach.us

  - explain how we handle non-technical issues at present

  - explain what is done to mitigate the TC being a nuclear option, plus
possibility of using former TC members for this

id:tslft9br4yq@suchdamage.org

  - when it comes to non-technical issues, we should consider focusing
on the problem of replacing maintainers, as we're the only body that
can do this

  - descriptions of how replacing maintainers doesn't work so well atm

id:011719ac-d3a1-7dd4-02ad-aeb5b74a3...@debian.org

  - useful remarks on private discussions

  - what could go wrong if we allow some way of doing design work
[I think Matthew is onto something important here]

  - separate body which is not one of last resort.

There were some other messages which were certainly interesting, but
which I didn't think could be actionable within our current conception
of the scope of the reform project.  But we could come back to them
after the current project has concluded.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Dispute resolution in Debian

2020-07-29 Thread Sean Whitton
Hello,

On Wed 29 Jul 2020 at 03:26AM -07, Felix Lechner wrote:

> As a computer project, Debian's highest decision making body should
> probably be a Technical Committee. Current committee members who like
> to adjudicate more along human lines, under my proposal, may wish to
> join the Community Team.

So what you are proposing would correspond to the last of our
proposals -- try to remove the meditation role the TC presently has?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Dispute resolution in Debian

2020-07-27 Thread Sean Whitton
Hello Felix,

On Sun 26 Jul 2020 at 07:59PM -07, Felix Lechner wrote:

> I would model access to conflict resolution on the US courts. There
> should be two levels of jurisprudence: One is quick and easily like
> small claims, the other is for appeals. Both can issue rulings that
> bind everyone, including delegates and the DPL.
>
> Private side conversations should remain off-limits. They create an
> incurable attack surface that lowers credibility. Decision makers who
> expressed an opinion outside the official process must recuse
> themselves. To seek their opinion, please file a case.

Well, the TC is the closest thing we have to a court of last resort
indeed, but I think its members hope that it could be other things as
well -- most disputes in Debian do not require a court of last
resort-style response.

Do you think it shouldn't have those other roles, maybe?  That would
correspond to the last of our proposals, I think.

> As Sean wrote, many problems at Debian are social in nature, I would

The text it from the whole committee, I was just the messenger :)  (and
marga did most of the work)

> make the Community Team the first legal instance before a party can
> appeal to the Technical Committee. Cases at Community Team level
> should be heard before a single member unless someone requests a
> hearing en banc. That effectively makes the Technical Committee
> Debian's Supreme Court (which hears all cases). In some way, this
> resembles Sean's Proposal 2.
>
> Like any court, the Community Team and Technical Committee should be
> able provide independent solutions of their own design. Ideally, the
> judges at the lower level, i.e. the Community Team, would be elected.

I think we think of the community team as mostly about the CoC -- not
just strict violations but conformance with its spirit -- whereas the TC
is about disagreements which do not involve (or do not primarily
involve) CoC issues.  In which case, the relationship between the two
would not really fit the model you suggest.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Rethinking the role of the TC

2020-07-26 Thread Sean Whitton
Hello,

On Sun 26 Jul 2020 at 08:47AM -07, Sean Whitton wrote:

> It's late in the day but I would like to suggest including this
> paragraph in the document in some form.

Thank you for doing this in commits today.  I'd like to suggest going a
bit further, however -- how about this:

As work done inside the Debian is inherently technical, it's hard
for an issue to be *purely non-technical*, there's always something
technical behind the conflict.  But in many conflicts, the *issue
that needs solving* is of a social nature rather than a technical
nature.  In this sort of situation the TC members can readily
observe that making a decision on the technical issue will not
really help matters, but it is the only thing the TC is actually
empowered to do.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Rethinking the role of the TC

2020-07-26 Thread Sean Whitton
Hello,

On Thu 23 Jul 2020 at 07:40PM -03, David Bremner wrote:

> I think it makes sense to formalize the "I'm thinking of bringing the
> following issue to the TC" discussions that already happen, to reduce
> the amount that people need to rely on existing personal relationships.

Might be good to include this in the doc?

> I don't know whether this is a point in favour or against this proposal,
> but I don't think developers are always that great at trying other ways
> of resolving problems before bringing them to the TC. This is related to
> the issue of mediation above.

I think the idea might be to accept that people aren't very good at this
and try to help them earlier.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Rethinking the role of the TC

2020-07-26 Thread Sean Whitton
Hello Marga,

I'm sorry I didn't reply sooner.

On Sat 18 Jul 2020 at 07:50PM +02, Margarita Manterola wrote:

> This is true, TC members are expected to be able to deal with "social
> issues". But still when issues arrive at our doorstep and we come to the
> conclusion that there's no technical issue to decide upon, we are
> usually left wondering what to do about them. In other words, if the
> problem is that two members of the community are clashing in the way
> they communicate and there's no option A or option B to select from, the
> TC is ill-equipped to deal with that.
>
> [...]
>
> As work done inside the Debian is inherently technical, it's hard for an
> issue to be *purely non-technical*, there's always something technical
> behind the conflict.  But in many conflicts, the _issue that needs
> solving_ is of a social nature rather than a technical nature.

It's late in the day but I would like to suggest including this
paragraph in the document in some form.

> I think clarifying who's in charge of mediating social conflict between
> developers might help the TC, whether the TC is that body or not.
>
> If we (as in the Debian project) decide that the TC should be in charge
> of mediation between developers (as long as there's no CoC violation),
> we can establish processes to do that. Probably add a few points to the
> constitution that clarify this role, how it works, etc.  That way,
> developers can come to us and understand what they can expect from us in
> this situation.
>
> If we decide that a different body (Community Team or a new one) should
> be in charge of mediation, then we can re-direct social issues to this
> team and stop wringing our hands when there's no technical option to
> select.

I see what you mean now -- the existence of something technical
somewhere within the issue prompts the dispute to be brought to the TC,
but if the TC makes a decision on the technical side of the dispute, it
won't really help anything; the TC members can see that, but the only
thing they can do is 'solve' the technical side of the dispute, which is
not very useful.

So, you're not really talking about those very rare, purely
non-technical, non-CoC issues I mistakenly thought you had in mind.

>> With respect to the "separate responsibilities" proposal, I would like
>> to ask for more detail on how it is thought this could make the TC more
>> useful.  Right now I can't see how it would, given what I just wrote
>> about how social issues tend to come throughly tangled up with
>> technical
>> ones, except for the purely non-technical, non-CoC issues, which the TC
>> does not presently have responsibility for anyway.
>
> Well, that option is very much in the air, but I wanted to include it
> because it had been floated around in this mailing list and also during
> the talk at DC19.  The goal of that option is to basically abolish the
> TC as it is now, and in its place construct new teams that are better
> equipped to deal with each type of problem (advice & guidance, social
> conflict, technical conflict).
>
> Some developers take issue at the fact that the TC has too much power.
> So, splitting it into pieces would reduce the amount of power that each
> piece has. If we decided that this was the way to go, we'd need to work
> on the wording of exactly what each piece is in charge of.

I saw your reply to Gunnar, on salsa, that this is mostly included for
completeness.  I'm on the fence about whether that's a good idea.

If no-one in the TC wants to pursue this, then I'm concerned that
starting a discussion on it is not going to achieve anything, and lead
to fractious and overly general discussions like we saw regarding the
formation and the delegation of the Community Team.  If someone outside
the TC wanted to pursue something like this, it would of course always
be open to them start that discussion and draft the GR proposal.

On the other hand having it on the list of proposals could forestall
"what about ..."  discussion from people who aren't really in favour of
the option but are inclined towards discussing each possibility.

In the end, I'm happy to trust your judgement on whether completeness is
a good reason to keep this in, but I do think that avoiding
subdiscussions that will go nowhere but have the potential to raise the
temperature is something that teams starting discussions within Debian
should consciously try to do, given how the past year has been on the
mailing lists.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Request for input -- rethinking the role of the TC

2020-07-18 Thread Sean Whitton
Dear Ian,

On Sat 18 Jul 2020 at 10:16AM -07, Sean Whitton wrote:

> On Sat 18 Jul 2020 at 04:29PM +02, Margarita Manterola wrote:
>
>> The doc collects the main problems that have been raised about the TC
>> and a bunch of proposals of what we can do about it. Neither list is
>> complete and your input is welcome.
>>
>> I've created it as a Markdown doc in our git repo and created a merge
>> request for it, so if you want, you can add your comments to that MR:
>> https://salsa.debian.org/debian/tech-ctte/-/merge_requests/1
>
> I think that the document is well-written.  Thank you for working on it.
> I am particularly keen to discuss the "private discussion", "allow
> design work" and "allow the TC to be invoked early" proposals.  Your
> descriptions of those seem complete.

As the original author of our constitution, I would like to ask you to
take a look at the three proposals for TC reform I list in the quoted
message.  Would it be possible for you to summarise the rationale for
these restrictions on how the TC works, or provide us some links to old
discussions, please?

I am hoping that this can help us better determine precisely how to
loosen these restrictions.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Rethinking the role of the TC

2020-07-18 Thread Sean Whitton
Hello Marga,

On Sat 18 Jul 2020 at 04:29PM +02, Margarita Manterola wrote:

> The doc collects the main problems that have been raised about the TC
> and a bunch of proposals of what we can do about it. Neither list is
> complete and your input is welcome.
>
> I've created it as a Markdown doc in our git repo and created a merge
> request for it, so if you want, you can add your comments to that MR:
> https://salsa.debian.org/debian/tech-ctte/-/merge_requests/1

I think that the document is well-written.  Thank you for working on it.
I am particularly keen to discuss the "private discussion", "allow
design work" and "allow the TC to be invoked early" proposals.  Your
descriptions of those seem complete.

At the present time, I am not convinced of the value of discussing the
"mediation body" and "split responsibilities" proposals, because I don't
yet see how they are in scope for a reform project led by the TC.  I'll
try to explain what I mean, and then maybe you could expand your
descriptions, ideally with some concrete examples, such that I and
others can see better what you're getting at.

Non-CoC social issues often arrive tangled up with the technical issues
that come before the TC, such that the project already expects the TC to
mediate, and people are appointed to the TC on the basis that they will
be capable of mediating.

Then with respect to the "meditation body" proposal, the point seems to
be for the project to assign mediation responsibility for purely
non-technical, non-CoC social issues to a new body, or to an existing
body, the TC, which is meant to already have people capable of mediating
on it.

It might be a good idea for Debian to do that, but the sense in which it
might make the TC more useful to Debian is quite different from the
three proposals I said I am particularly keen to discuss, which are
about making the TC more useful for issues it already has responsibility
for.

So, ISTM that a project to assign responsibility for mediating non-CoC,
purely non-technical issues is a distinct project from that of
rethinking how the TC handles what it already has responsibility for,
and moreover, it is not clear to me such a project should be led by the
TC.

With respect to the "separate responsibilities" proposal, I would like
to ask for more detail on how it is thought this could make the TC more
useful.  Right now I can't see how it would, given what I just wrote
about how social issues tend to come throughly tangled up with technical
ones, except for the purely non-technical, non-CoC issues, which the TC
does not presently have responsibility for anyway.

Additionally, in light of the discussions we had about the formation and
delegation of the Community Team, I am concerned that we could end up in
quite fractious, overly general discussions about the role of mediation
in mostly-but-not-wholly-technical projects like ours.  So I would like
to have a concrete conception of how this could make the TC more useful
before going down that road.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#965080: Resignation + Call for votes for new Chair

2020-07-15 Thread Sean Whitton
Hello,

On Wed 15 Jul 2020 at 09:05PM +02, Margarita Manterola wrote:

> I am calling for the election of a new Chair of Debian Technical
> Committee by announcing my resignation as chair effective one week from
> now. In accordance with Section 6.1.7 of the Debian Constitution, the
> vote runs until all members have voted, or until my resignation takes
> effect.
>
> The ballot is the following:
>
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
>  A : Philip Hands
>  B : Margarita Manterola
>  C : David Bremner
>  D : Niko Tyni
>  E : Gunnar Wolf
>  F : Simon McVittie
>  G : Sean Whitton
>  H : Elana Hashman
>
> ===END===

I vote: B > C > A = D = E = F > G = H

-- 
Sean Whitton


signature.asc
Description: PGP signature


[Draft] requesting questions for debconf20 BoF

2020-07-04 Thread Sean Whitton
Hello,

Here is my attempt to fulfill my action item from our most recent
meeting.  I think the next step is for marga to append her write-up in
accordance with my suggestion to highlight talking points, if that idea
seems like a good one.  Maybe use square brackets or something and write
questions to the wider community inside those.

=

Hello everyone,

The Technical Committee are planning a BoF for DebConf20.  Most of it
will be a Q session, and we want to collect questions in advance, in
addition to answering {follow-up ,}questions asked during the session.

A general hope is that this should increase the quality of our answers,
but more specifically, we want to use the BoF to firm up our ideas about
the future of the TC, and we think this goal will be better served if
talking points are submitted in advance.

Please find below a description of our current ideas about the future of
the TC.  We have highlighted points and issues which we think should be
discussed at the BoF, so if you have ideas or questions to ask
specifically on those points, please do submit them.

More general questions are welcome too.

Based on what we receive, we will curate a list of talking points before
the session, and structure the BoF around them.

Please address your questions and talking points to
, preferably in reply to this message for
easier collation.

=

[the plan]

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED

2020-06-23 Thread Sean Whitton
Hello,

On Tue 23 Jun 2020 at 01:47AM +02, Jonas Smedegaard wrote:

> Quoting Sean Whitton (2020-06-22 23:26:37)
>> Would someone want to use libjs-katex without nodejs installed?
>
> Yes: Pandoc can produce output which uses katex rendered with the
> Javascript interpreter of web browsers, not on OS-bound Javascript
> rendering like Node.js.
>
> Currently Pandoc suggests node-katex, but pulling in Node.js is unneeded
> baggage.  For some users it may even be bad: Node.js may not be covered
> by security support for as long as Firefox (due to the extraordinary
> treatment of Firefox in stable Debian).

Thanks.  I think at this point we probably need to wait to hear from
Bastian, who processed the REJECT.  In the meantime, it would be good to
reupload with the reason for the binary package split documented, as
previously described.

-- 
Sean Whitton



Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED

2020-06-22 Thread Sean Whitton
Hello Pirate,

On Mon 22 Jun 2020 at 12:58AM +0530, Pirate Praveen wrote:

> We usually use Provides instead of splitting when we can remove the Depends 
> on the interpreter. For example node-clipboard provides libjs-clipboard.js. 
> This works when the node package does not ship a user facing significant 
> executable. User facing executable as separate binary was recognized as a 
> valid reason by CTTE in the ruling I quoted in my first reply.
>
> In case of this particular package, katex binary also provide a command line 
> interface via katex command. So we cannot drop the depends on nodejs (rc bug, 
> nodejs is not an optional component but the interpreter needed to run the 
> katex program). Avoiding unnecessary dependency on interpreters was achieved 
> in all previous instances by removing the dependency on pure libraries. We 
> expect whichever user facing program depending on the library to set Depends 
> on the interpreter. For example gitlab depending on nodejs is enough for 
> node-clipboard to satisfy dependency on nodejs. In this case katex itself is 
> a user facing program not tied to nodejs development (it is used for maths 
> typesetting). So we cannot reasonably expect a user wanting to use katex will 
> have nodejs installed already.

Would someone want to use libjs-katex without nodejs installed?

> I thought the CTTE guideline on this specific case of user facing executable 
> was enough. They could have just asked for an explanation before rejecting.

You should ensure it's visible in the source package, in
README.{source,Debian} and/or d/changelog.

-- 
Sean Whitton



Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED

2020-06-21 Thread Sean Whitton
[speaking as an FTP team member, not ctte member, though this is *not*
an official statement made on behalf of the whole FTP team]

Hello Jonas,

On Sun 21 Jun 2020 at 10:48AM +02, Jonas Smedegaard wrote:

> Could you please elaborate a bit on your opinion that the introduced
> split into katex and libjs-katex is unnecessary?

I have not looked at this particular package, but here is what I
understand to be the team's consensus: the FTP team wants to see some
technical purpose which is served by the binary package split, to
justify taking up more space in the Packages file.  We will also object
if this technical purpose could be easily served by something other than
a binary package split (e.g. by adding Provides: entries).

So I would assume that the FTP team member who processed this upload
couldn't see how a technical purpose was being served by the split.  If
Pirate could explain some technical purpose that was missed that would
be helpful.

I don't think that the bar is particularly high here.  Even if an FTP
team member wouldn't themselves solve the problem by introducing a
binary package split, if it's clear that the maintainer has consciously
chosen to use a binary package split to solve a problem and that's a
reasonable way to go about solving the problem, we'll sign off on it.

-- 
Sean Whitton



Re: DebConf20 Moves Online

2020-06-12 Thread Sean Whitton
Hello,

On Fri 12 Jun 2020 at 10:46AM -03, Antonio Terceiro wrote:

> So, please [submit your talk, sprint, and BoF proposals][1] for DebConf
> 20 Online.
>
> [1]: https://debconf20.debconf.org/cfp/

Should we try to organise a virtual Meet the Technical Committee?

-- 
Sean Whitton



Re: tech-ctte: Call for votes on TC membership of Elana and Sean

2020-06-01 Thread Sean Whitton
Hello Jonathan,

I'm not presently a committee member, but fwiw I think this version
(mentioning both bugs) is fine to send out.  Thank you for your efforts.

A few brief comments inline.

On Mon 01 Jun 2020 at 11:24PM +02, Jonathan Carter wrote:

> Since the last appointment update for the Debian
> Technical Committee[1], the terms of Didier Raboud
> and Tollef Fog Heen have expired.
>
> Many thanks to both of them for their service.
>
> Margarita Manterola is the current chairperson of
> the Debian Technical Committee.

I agree with you that it is a good idea to mention these items within
d-d-a mail about new appointments, though I don't think it would be
worth sending a whole d-d-a mail if all that happened was a change in
chair or a term expiring.

The constitution does specifically use 'chair' not 'chairperson' and we
did have a vote on that, so that might be a reason to use that in
official mail like this one.

> The Technical Committee now consists of:
>
>  * Margarita Manterola  (chairperson)
>  * Philip Hands 
>  * David Bremner 
>  * Niko Tyni 
>  * Gunnar Wolf 
>  * Simon McVittie 
>  * Elana Hashman 
>  * Sean Whitton 

Might be worth alphabetising by last name, with the possibly exception
of the chair.  Not sure.  Just thought I'd mention it.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: tech-ctte: Call for votes on TC membership of Elana and Sean

2020-05-28 Thread Sean Whitton
Hello,

On Thu 28 May 2020 at 09:39AM -07, Sean Whitton wrote:

> I don't believe that odyx, philh or tfheen are members anymore; their
> terms expired.  marga is the current chair.

Er.  Phil is still a member.  Sorry :)

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: tech-ctte: Call for votes on TC membership of Elana and Sean

2020-05-28 Thread Sean Whitton
Hello Jonathan,

On Thu 28 May 2020 at 06:27PM +02, Jonathan Carter wrote:

> Proposed delegation update,

It's not a delegation, just an appointment, fyi.

> As defined by our constitution (§6.2.2), the Debian
> Technical Committee has recommended the appointment of:
>
>  * Elana Hashman 
>  * Sean Whitton 
>
> I am extremely happy to follow their recommendation and hereby
> appoint Elana and Sean as members of the Technical Committee, effective
> immediately.
>
> For reference, their nominations and votes are recorded at:
>
>  * https://bugs.debian.org/961156

You probably want to mention both #961153 and #961156.

> The Technical Committee now consists of:
>
>  * Didier Raboud  (chairman)
>  * Philip Hands 
>  * Tollef Fog Heen 
>  * Margarita Manterola 
>  * David Bremner 
>  * Niko Tyni 
>  * Gunnar Wolf 
>  * Simon McVittie 
>  * Elana Hashman 
>  * Sean Whitton 

I don't believe that odyx, philh or tfheen are members anymore; their
terms expired.  marga is the current chair.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Possible improvements to the Policy Changes Process (was: Re: Thinking about Delegating Decisions about Policy)

2019-06-23 Thread Sean Whitton
 an
> post-promulgation objection is made which raises a substantial issue
> that ought to be dealt with.
>
> While vacillation is undesirable, making it easier and less socially
> costly to handle mistakes, will make it easier to make changes.

I agree that this could help a lot.  I have certainly felt hesitation
before committing a change, thinking "maybe we should give people more
time to raise issues with this change", and this would avoid that sort
of situation.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Managing Frozen text when the TC Decides Policy

2019-06-23 Thread Sean Whitton
Hello,

On Sun 19 May 2019 at 09:14am -0400, Sam Hartman wrote:

> >> I think the policy editors could handle this by deciding amongst
> >> themselves how they want to interact with the TC and then writing
> >> a note to the TC along the following lines adapted based on what
> >> the policy editors think the write answer is:
>
> Sean> Thank you for taking the time to think about this carefully,
> Sean> but I would like to suggest that we set is aside until and
> Sean> unless we have a concrete situation in which the Policy
> Sean> Editors feel that we can't make a change to the Policy Manual
> Sean> because of a particular T.C. decision.
>
> Well, we have a situation now where a member of our community (Bill) is
> uncomfortable with the TC being asked to take on one of the tasks that
> our constitution lets the TC take on.
> I think that concern is something that we should address now since it
> has arisen.
>
> If you as policy editors think that you can reassure Bill and tell him
> that you believe you could work with the TC were that situation to come
> up, then I think you could adress Bill's concern now without addressing
> specifics.
>
> Right now we have a situation where someone is concerned that one part
> of Debian could not work with another.
> I'd like to get that cleared up.  If the policy editors are confident
> that they can defer things, I think that would be a fine solution.

I'm sorry that I wasn't able to reply to this sooner.

I feel able to reassure everyone that, indeed, the Policy Editors would
be able to work with the T.C. to avoid the sort of situation Bill is
worried about.

When I took on the role of Policy Editor I subscribed myself to the
T.C.'s mailing list.  I consider it part of the role to keep abreast of
their activities.  In light of the present thread, I'll keep in mind the
need to flag to the T.C. places where decisions they are about to take
might have an impact on the practicalities of the Policy Changes
Process, such as the issue of frozen text.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Concluding "What should happen when maintscripts fail to restart a service?"

2019-06-21 Thread Sean Whitton
Hello Gunnar,

On Thu 20 Jun 2019 at 11:18am -0500, Gunnar Wolf wrote:

>> ~ ~ ~
>>
>> In #904558, I did not ask the T.C. to rule on what maintscripts should
>> do when they fail to restart a service.  Rather, I asked them to weigh
>> in on the decision between the options described above, given that the
>> Policy Changes Process had failed to achieve consensus.  However, in the
>> message closing #904558, the T.C. indicated that they declined to issue
>> a ruling about what maintscripts should do when they fail to restart a
>> service.  So the second option described above, corresponding to the
>> 'ctte' usertag, has been taken off the table.
>>
>> That leaves us with the question of whether to leave #802501 open, in
>> the absence of the possibility of closing it by having the T.C. make a
>> call.  Given that this bug has already been filed (at least) twice, I
>> think it would be best for us to leave it open.  So I'm tagging
>> wontfix+stalled.
>
> I want to interpret this wontfix+stalled, and the TC answer ("The
> Technical Committee does not engage in design of new proposals and
> policies") don't mean this problem will just lay dormant and unsolved
> forever. As Marga said in her mail closing this bug, «While we
> recognize that this is a problem worth fixing, this is not something
> that we can fix as a body and need the help of the Developers to do
> it.»
>
> I want to insist on our recommendation to create a work group of
> developers to tackle this issue. Maybe we can start it off as a BoF
> session in DC19?

My reading of the conclusion to #904558 is that the recommendation to
form a working group is a recommendation that can be directed only to
the developer body as a whole, not to the Policy process.  That's
because actually implementing in the archive some new mechanism for
maintscripts is a prerequisite to any Policy change requiring packages
to use that new mechanism.  In other words, what the working group would
be tasked with doing is beyond the scope of the Policy process.  We do
design work as part of the Policy process, but we don't write code.

Assuming that the T.C.'s recommendation is the right way to proceed
here, and someone doesn't come up with any other way to unblock things,
the wontfix+stalled status will remain until and unless the working
group actually forms, designs and implements something, and starts using
it in the archive.  There is no role for the Policy process (and thus no
role for the Policy Editors qua Policy Editors) until that occurs.

So, by all means insist on the recommendation, but so far as I can tell
that's something which does not involve either the Policy process or the
T.C., but simply the body of Debian contributors qua contributors.

Stepping back a bit, tagging this bug wontfix+stalled is part of the
broader attempts, in which the Policy Editors are engaged, to more
sharply delineate the boundaries of the Policy process.  We want to get
to the point where the only bugs that we have listed are either
highly actionable, or tagged wontfix.  For a bug to be highly actionable
is for it to be the case that someone with enough time and background
knowledge can sit down, think through the problem, and come up with at
least a first version of a change proposal.

I think that a large number of very-difficult-to-action bugs strongly
discourages people from getting involved.  It makes Policy seem like a
sprawling, unmanageable morass of difficult problems.  That isn't how
things are, because while there are indeed a lot of hard problems, they
are largely independent of each other, and tackling individual
debian-policy bugs really does improve Debian.  However, it is much
harder to see that when half of the open bugs are more than five years
old yet not tagged wontfix.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Concluding "What should happen when maintscripts fail to restart a service?"

2019-06-20 Thread Sean Whitton
tag 802501 + wontfix
user debian-pol...@packages.debian.org
usertag 802501 = normative stalled
thanks

Hello,

In #904558 I asked the T.C. for advice about how to move #802501
forward.  Their ultimate response was to recommend that a working group
of developers come up with some method, other than exiting nonzero, for
a maintscript to indicate that it failed to restart services.  Let me
take this opportunity to thank all those who were involved in #904558.

In this message, I seek to explain my understanding of what the closing
of T.C. bug #904558 means for debian-policy bug #802501, and those
merged with it.  Apologies for the length.  I wanted this general sort
of reasoning to be recorded somewhere for reference in future
discussions.

~ ~ ~

When the Policy Changes Process fails to establish consensus, we have a
few options.  If we think that consensus hasn't been established only
because no-one has volunteered to come up with an adequately detailed
response to the problem uncovered by the filing and discussion of the
bug, and the bug has been open for a while with no evidence of anyone
working on it, we (the Policy Editors) will often just close the bug.
We don't want such things to stick around, clogging up the list of open
issues in a way that's demotivating.  This is the 'obsolete' usertag.

If we think that consensus hasn't been established because there are
good arguments on all sides, but we (the Policy Editors) additionally
think that argument to determine the very best solution is less
important right now than settling on one of the possible solutions
rather than remaining in further discussion, then we can refer the bug
to the T.C. to make a call between the competing options.  This was, I
think, the intended purpose of the 'ctte' usertag, but we haven't been
using it.

Finally, if we don't want to refer the bug to the T.C. -- generally
because it's not important enough -- but we think that closing the bug
would be counterproductive because someone else will just open a new bug
raising the same issue again at some near point in time, we can just
leave the bug open, as a kind of placeholder to hopefully reduce the
number of duplicate bugs filed.  I just added a 'stalled' usertag for
this case.

The 'obsolete', 'ctte' and 'stalled' usertags are meant to be used in
addition to the 'wontfix' tag.

~ ~ ~

In #904558, I did not ask the T.C. to rule on what maintscripts should
do when they fail to restart a service.  Rather, I asked them to weigh
in on the decision between the options described above, given that the
Policy Changes Process had failed to achieve consensus.  However, in the
message closing #904558, the T.C. indicated that they declined to issue
a ruling about what maintscripts should do when they fail to restart a
service.  So the second option described above, corresponding to the
'ctte' usertag, has been taken off the table.

That leaves us with the question of whether to leave #802501 open, in
the absence of the possibility of closing it by having the T.C. make a
call.  Given that this bug has already been filed (at least) twice, I
think it would be best for us to leave it open.  So I'm tagging
wontfix+stalled.

~ ~ ~

In filing #904558, I made an alternative suggestion to the above:

> As a Policy delegate I want to move this issue along, and I can see
> three ways of doing that:
>
> 1. write a patch to explicitly state in Policy that what happens when a
>service (re)start fails in a maintscript is left up to package
>maintainer discretion, and close the bugs
> [...]

I no longer think this would be useful enough to have in Policy, but I'd
like to hear from anyone who disagrees.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Managing Frozen text when the TC Decides Policy

2019-05-15 Thread Sean Whitton
Hello Sam,

On Sat 11 May 2019 at 01:24PM -04, Sam Hartman wrote:

> I agree that it would generally be unfortunate if we had policy text
> that could not be changed by the policy process.  I can see rare
> situations where it might happen: we might have legal advice requiring
> specific text be included in packages under certain circumstances.  And
> in such a situation it might well be that we'd expect the policy editors
> to go back and check with lawyers before changing that frozen text.

We actually already have this situation with several bits of text that
the Policy Editors don't consider ourselves able to edit without
ftpmaster approval.  See, for example, #904729 and #912581.

> I think the policy editors could handle this by deciding amongst
> themselves how they want to interact with the TC and then writing a note
> to the TC along the following lines adapted based on what the policy
> editors think the write answer is:

Thank you for taking the time to think about this carefully, but I would
like to suggest that we set is aside until and unless we have a concrete
situation in which the Policy Editors feel that we can't make a change
to the Policy Manual because of a particular T.C. decision.

It's very complicated and time-consuming to discuss in the abstract, and
it has not actually been a problem in at least the last two to three
years.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Thinking about Delegating Decisions about Policy

2019-05-15 Thread Sean Whitton
Hello Sam,

On Fri 10 May 2019 at 03:57PM -04, Sam Hartman wrote:

> What are people's thoughts about this?
>
> Will this approach work for the TC and policy editors?

I think that the concrete suggestion you're making is that when a
question that comes before the T.C. is something that could be solved by
patching the Policy Manual, the T.C. should respond to the question by
opening a bug against the Policy Manual, and suspending the T.C. bug
until it becomes clear whether or not that debian-policy bug is going to
reach consensus?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Re: Thinking about Delegating Decisions about Policy

2019-05-15 Thread Sean Whitton
Hello Ian,

On Mon 13 May 2019 at 02:50PM +01, Ian Jackson wrote:

>> we delegated managing the process to the policy editors, but not the
>> actual policy decisions.  They make consensus calls.  They use their
>> judgment in a lot of ways.
>
> That is a decision *of* the policy editors.  When the constitution was
> first adopted, and for some time afterwards, the policy editors
> themselves made judgement calls about merit, rather than simply trying
> to assess consensus.
>
> [...]
>
>> But at least under the current process, the policy editors cannot  just
>> use their personal judgment to decide what policy is absent a consensus.
>
> The policy editors collectively could decide to change the process.
> The process is a creation of the policy editors, not of the DPL nor of
> the rest of the project.

Firstly, let me confirm that I share this understanding of what powers
the Policy Editors formally possess.  I actually wrote it into Policy in
a recent release, section 1.3.2.

(I am also responsible for moving the Policy Changes Process into the
Policy Manual itself as an appendix.  It was not my main motivation at
the time, IIRC, but in fact the change has made the status of the Policy
Changes Process a bit clearer than when it was just a wiki page.)

> IMO the biggest problem is the principle that policy should always
> follow practice rather than lead it - even if the project has rough
> consensus about the direction.  I really don't think that is best.
>
> There is a missed opportunity here.  The policy editors and the policy
> list have a good reputation and a lot of legitimacy.  That comes from
> their practice of caution, of consulting widely, and seeking rough
> consensus.
>
> I wouldn't want to change that dramatically but a small change from
> the policy editors would go a long way.  For example, to be willing to
> countenance making recommendations which have rough consensus, and
> seem to the editors like a good way forward, but which are followed
> only occasionally or patchily.
>
> That would not involve goring anyone's ox, so it would not undermine
> the policy team's political capital.  Obviously any change might be
> opposed by someone but I doubt such a change in policy practice would
> meet much opposition.

The idea that Policy should always lag behind practice is something that
I find very difficult to assess.  If you are thinking of Debian as a
large number of people furiously innovating at the borders and
exchanging ideas with each other in the form of uploads, then it makes
complete sense.

On the other hand, to the extent that we're a group of people struggling
to communicate best practices to large numbers of people working largely
independently on mostly maintainance work, it seems a lot less helpful.

(Debian is, of course, both of these things.)

My current strategy, when

- it seems like something is important and should be changed, but
- it has not yet been implemented in the archive, or
- in some other sense lacks a clear consensus,

is to refer the case to the T.C.

I think your suggestion is that in at least some such cases we should
lower our standards for what is required for a clear consensus?  If so,
am I right in thinking this would not actually require any changes to
the Policy Changes Process?

> Additionally I think the formal proposer/seconder scheme can be
> awkward.  Again I think the policy editors adopted it because they
> didn't want to be in the line of fire when difficult decisions are
> being made, and perhaps because they didn't want to try to become
> experts in everything.  But it means that uncontroversial changes can
> languish.

Do you (or anyone else) have any concrete ideas for simplifying the
proposer/seconder scheme, without significantly reducing the oversight
on changes, even uncontroversial ones?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: CTTE decision on vendor-specific patch series (bug #904302)

2018-11-17 Thread Sean Whitton
Hello,

On Tue 13 Nov 2018 at 07:22PM +0100, Tollef Fog Heen wrote:

> The technical committee was asked in bug #904302 to decide whether to
> allow the use of vendor-specific patch series in the Debian archive.
>
> The following resolution was passed:

Thank you all for your work on this.  Should be in the next Policy
release.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Whether vendor-specific patch series should be permitted in the archive

2018-10-02 Thread Sean Whitton
Hello,

On Tue 02 Oct 2018 at 07:48PM +0200, Tollef Fog Heen wrote:

> Given the entire decision has been delegated to us, I think we should,
> yes.  If we'd just been asked to decide on a matter of technical policy,
> that would have been slightly different.

I think that the wording of my initial mail was ambiguous with regard to
which one of these was being requested.

I would be grateful if you would micromanage just enough that there
isn't anything controversial left for people to disagree about :)

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Whether vendor-specific patch series should be permitted in the archive

2018-09-16 Thread Sean Whitton
Hello,

On Sat 15 Sep 2018 at 07:06PM +0200, Tollef Fog Heen wrote:

> A first draft is below, feedback on wording and content appreciated.

LGTM, thank you.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

2018-08-19 Thread Sean Whitton
Hello Adrian,

On Sun 19 Aug 2018 at 09:51PM +0300, Adrian Bunk wrote:

> Why is "The source" what you get after dpkg applied patches,
> but before debian/rules applied patches?

Because we define the package build as something that starts when you
invoke the debian/rules script.

> For a user it doesn't make a difference which tool applies the patches.

In my mind, it does; it matters whether or not it is part of the package
build.  That's just my expectation of what reasonable users will think.

We're discussing what users will reasonably expect.  If you and I have
different intuitions about the expectations that reasonable users will
form, we're going to have to agree to disagree.  Neither of us is in a
position to conduct field research on this question (afaik!).

> Note that you were also arguing based on a different source
> definition:
>
> On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
>> For example, someone might want to use a Debian system to investigate a
>> bug on an Ubuntu system.  They might begin by downloading some source
>> packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
>> they will form the reasonable expectation that unpacking these source
>> packages will get them the code running on the Ubuntu system they are
>> debugging.
>
> This would be useful for debugging problems.
>
> But it is important to understand that in the general case there will
> always be cases where the code running on your system will depend on
> the architecture of your system - after applying patches the sources
> might be architecture-specific.

Unless I'm missing something, that can only be true when the application
of patches to which you refer occurs during the package build.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

2018-08-18 Thread Sean Whitton
Hello,

On Fri 17 Aug 2018 at 07:36PM +0300, Adrian Bunk wrote:

> The main misconception is that there would always be *the* source.
>
> Steps you might have before the compilation starts:
> 1. dpkg unpacks upstream sources
> 2. dpkg applies patches
> 3. debian/rules unpacks upstream tarballs as part of the build
> 4. debian/rules applies patches based on distribution
> 5. debian/rules applies patches based on release
> 6. debian/rules applies patches based on architecture
>
> What is "the source running on their Ubuntu system" for src:gcc-8?
>
> This package skips steps 1 and 2, but does all of steps 3-6.

But all of steps 3--6 are part of the package build.

"The source" is what you get after steps 1 and 2.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

2018-08-17 Thread Sean Whitton
Hello,

On Fri 17 Aug 2018 at 12:32PM +0100, Ian Jackson wrote:

> In general, I think package builds should not pay any attention to
> dpkg-vendor.  Can I please add that request to the TC's deliberations ?

This is about package builds, not the unpacking of source packages, so
is surely a completely separate issue (which we should discuss at the
level of Debian Policy, not refer directly to the T.C.).

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Whether vendor-specific patch series should be permitted in the archive

2018-08-17 Thread Sean Whitton
Hello Marga,

On Wed 15 Aug 2018 at 11:35AM +0200, Margarita Manterola wrote:

> Apart from this, the concern that has been raised about making packages
> instabuggy is valid. I would like our decision to include that this
> should
> be SHOULD first, giving maintainers a window of time to fix their
> packages
> and only become a MUST once those packages have been fixed (or something
> along those lines, maybe after buster is released).

I'd like to suggest giving a window of time.  Otherwise the policy
process alone won't really have the authority to switch from
should->must.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904302: Why outlawing vendor-specific patch series would be a bad idea

2018-08-17 Thread Sean Whitton
Hello,

On Fri 17 Aug 2018 at 12:01AM +0300, Adrian Bunk wrote:

> On Mon, Jul 23, 2018 at 09:22:17AM +0800, Sean Whitton wrote:
>> For example, someone might want to use a Debian system to investigate a
>> bug on an Ubuntu system.  They might begin by downloading some source
>> packages from the Ubuntu mirrors.  Since they obtained them from Ubuntu,
>> they will form the reasonable expectation that unpacking these source
>> packages will get them the code running on the Ubuntu system they are
>> debugging.
>
> This is not a "reasonable expectation", this is a bogus assumption.
> And users should be clearly told that investigating Ubuntu problems
> on a Debian system is not a good idea - the supported way for that
> is a chroot (or some more sophisticated virtualization solution).

People don't expect that running dpkg-buildpackage on a Debian system
would get them the binary package running on an Ubuntu system.  That's
different from the expectation that the source they get is the source
running on their Ubuntu system.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#904558: What should happen when maintscripts fail to restart a service

2018-08-10 Thread Sean Whitton
Hello,

Thank you for your reply.

On Thu 09 Aug 2018 at 09:19pm +0200, Tollef Fog Heen wrote:

> ]] Sean Whitton
>
>> The general question about which I am seeking advice: does the
>> T.C. think that Debian can be consistent on service (re)starts in
>> maintscripts, or is the best we can do to leave it up to package
>> maintainer discretion?
>
> I think we can give advice on what the default should be and that people
> should not stray from that unless they have particular reasons.  That
> advice might be more appropriate for the developers reference than
> policy, though.

I disagree -- it's about the contents of packages, so it should go into
Policy.  We can make it a recommendation rather than a requirement.

> Due to the variety and complexity of daemons in the archive, I would be
> reluctant to require complete consistency, there are likely various edge
> cases we have not thought about.

It would be useful to write something like this into Policy, rather than
it remaining silent on the issue.  It would be a fine resolution for the
Policy bug in question.

-- 
Sean Whitton


signature.asc
Description: PGP signature


  1   2   >