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

[Keith Packard]

Simon McVittie  writes:

> Should we be more specific than this in what we vote on, to avoid
> later having to adjudicate between developers who say that a particular
> implementation is or isn't merged-usr?

I think that and a transition plan are both key to this project. I
recently installed Debian from scratch on my HiFive unmatched board and
it got merged / and /usr. When I built packages on this device, they
created invalid packages as the shared library dependencies all listed
/lib instead of /usr/lib. That seems like a non-starter to me.

Any plan where a transitioning system cannot be used for ongoing Debian
development seems unworkable to me -- it leaves all active Debian
developers working on un-transitioned systems, which greatly reduces
test coverage from people in the best position to help fix things.

I do use a separate cowbuilder when creating packages to upload, and
that could be configured in un-transitioned mode, but I also regularly
debug packages on my native system as that offers much faster
development times.

> Guillem considers layout 1 to be broken and a mess. I don't agree,
> but I'm not a dpkg maintainer. We should be aware that mandating this
> implementation is likely to require some overruling.

From an architectural purity perspective, layout 1 'looks nicer'. As
that also matches what other distros are doing, it would make us more
consistent across the Linux ecosystem (I believe that's a good thing).

However, I believe only layout 2a would make it possible to build Debian
packages on transitioned systems. That seems necessary to me. We could,
in future, then transition from layout 2a to layout 1 once /lib (and
/bin?)  were no longer in the default search paths to cause invalid
packages to be created.

I don't understand the value of 2b; it's functionally similar to layout
1, but makes for additional work to create the shadow links, along with
consuming space for them. It also doesn't resolve the problem of
building packages.

> Sorry to derail this but I think we should be clear about what we're
> resolving.

I think you've added helpful clarification to the conversation, thanks!

-- 
-keith


signature.asc
Description: PGP signature

Bug#880014: #880014: Call for Votes for new TC member

[Keith Packard]

Didier 'OdyX' Raboud  writes:

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

I vote G > F

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: Modemmanager probing of unknown Devices

[Keith Packard]

Ian Jackson  writes:

> I intend to carry on and try to help do the Debian part of this, with
> NMUs as seem appropriate.  My earlier email suggesting an upload to
> experimental is part of that.  If the modemmanager maintainers would
> like to step in then that would be great of course.  Just let me know.

This seems fine to me; I think the TC as a body is happiest when
maintainers work things out collaboratively, using the NMU process
gently to help make the distribution better.

(Thanks for driving this; it's been a personal annoyance for years, just
not enough to get me to actually work on it)

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Sam Hartman  writes:

> Have I got that right?

Yes, I think you have summarized the issue accurately.

> However, for Debian and for the Technical committee, we need to consider
> what experience we want to give all our users and as a result value
> damage caused by false positives more highly than the upstream project
> might.

This does seem reasonable, but I haven't seen a concrete technical
proposal that would meet this goal.

Ian suggests asking the user, which seems like a fine goal, but I don't
think there's any plan for how to make this work in practice?

I made a suggestion (without my TC hat on) to not install modemmanager
by default. This is obviously easy to implement, however it also clearly
breaks the user experience for anyone who needs to use a modem to
download additional packages (e.g. modemmanager).

What I'd love to see is a patch that makes modemmanger behave better for
our users while remaining installed and operational. If it's useful
enough, it should be acceptable upstream as Debian is not the only
community affected by this particular problem.

(If only the USB standard had a class definition for 'serial device' that
was separate from 'modem device'.)

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

> This has gone far enough.  I would like to remind you of Constitution
> 6.3(5)

Here's what I prefaced my first remark with:

 (speaking as a Debian user, not as a TC member)

Perhaps I should have added this to each message I sent?

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

> But I should be able to use the same laptop to (1) control my machine
> tools or talk to my rpi or whatever (2) go online with a usb mobile
> modem when I'm out of the house.  Possibly even simultaneously.

That requires fixing the package instead of just getting it out of the
way, a significantly harder thing to manage.

I'm not saying your wrong. The simpler fix would make things better for
some people (those who use no USB modems, but do use other USB serial
devices), worse for others (those who use USB modems but not other USB
serial devices), and the same for a few (those who use both). The
question is whether the simpler fix would be a net positive for Debian
users, or a net negative.

Obviously, a "real" fix that asked the user whether a particular
device was actually a modem would be best for the third class of
people.

Of course, the simpler fix has the side effect of not installing
software or running I don't ever need and which serves only to annoy me.
So, for me, the simpler fix is even better...

> And, people shouldn't have to install support software to get their
> internet to work.

It's all a question of what support we install by default; there are
certainly plenty of network configurations which are not supported in a
default install. Are modems still common enough that supporting them by
default is worth the cost of wasting space and power on the remaining
machines which will never use one?

If it were just software that got installed and sat idle, I'd complain a
lot less. As it is, modemmanager does "stuff" by default, even if I
haven't asked it to. Software which runs on every machine by default
should be held to a higher standard than software which users explicitly
request. So, if we didn't install it by default, I'd be happy for it to
continue to suck.

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

> Also, AIUI modemmanager contains code to do things with the new-style
> MBIM dongles (which can also be done with the cli tools in
> mbim-utils).  But I definitely wouldn't suggest disabling its ability
> to work with AT-command modems, as they are still being sold.[1]

Yeah, I was just thinking that it would be easier to stop installing
support for modems by default than to actually fix modemmanager to
behave itself. It's certainly how I work -- apt remove modemmanager
solves a world of problems for me.

-- 
-keith


signature.asc
Description: PGP signature

Bug#877024: modemmanager should ask before messing with serial ports

[Keith Packard]

Ian Jackson  writes:

(speaking as a Debian user, not as a TC member)

> I'm afraid don't really want to do the work of writing a better UI.
> But I have provided a simple patch which at least makes the behaviour
> safe.

Would it be sufficient to simply stop installing this largely-useless
package at this point? In what environments do users typically have
modems which work with AT-style commands?

It would be far safer to not install this package than try to hack it up
to keep it from breaking systems. Simply removing it from 'depends' on
the handful of packages which currently list it would 'fix' this problem
with a minimum of fuss.

-- 
-keith


signature.asc
Description: PGP signature

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Keith Packard]

Tollef Fog Heen  writes:

> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote R > F

-- 
-keith


signature.asc
Description: PGP signature

Bug#865485: Voting for TC Chair

[Keith Packard]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> H: Niko Tyni 
> ===END===

I vote:

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

-- 
-keith


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new TC member

[Keith Packard]

Didier 'OdyX' Raboud  writes:

> I call for votes on the following ballot to fill a vacant seat in the TC. 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 recommends that Niko Tyni  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> N: Recommend to Appoint Niko Tyni 
> F: Further Discussion
> ===END

I vote N > F

-- 
-keith


signature.asc
Description: PGP signature

Bug#860520: Voting for TC Chair

[Keith Packard]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> ===END===

I vote:

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

-- 
-keith


signature.asc
Description: PGP signature

Bug#836127: Call for Votes for new CTTE Member

[Keith Packard]

Philip Hands  writes:

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

I vote A > B

-- 
-keith


signature.asc
Description: PGP signature

Bug#846002: Call for votes on resolution for #846002 (blends-tasks)

[Keith Packard]

Margarita Manterola  writes:

> I call for votes on the following resolution with regards to #846002:

I vote A > FD.

-- 
-keith


signature.asc
Description: PGP signature

Bug#830978: Browserified javascript and DFSG 2

[Keith Packard]

"Paul R. Tagliamonte"  writes:

> Traditionally, ftpteam has had to take this role, since it is the body
> that decides if an upload is fit for main.

Yup.

> I haven't talked in-depth with the rest of the ftpteam, but I assume
> they agree. CC'ing in case there's an objection.
>
> Not completely sure why this was filed with TC

Neither am I, but if the ftpteam wants advice from the TC on this issue,
we'd be happy to oblige. It doesn't seem like there's any serious
argument that the 'compiled' javascript delivered is DSFG-free though.

-- 
-keith


signature.asc
Description: PGP signature

Bug#830344: How should the TC help with a project roadmap?

[Keith Packard]

Margarita Manterola  writes:

> For documentation purposes, I list below my summary of the points that were
> raised during the Roadmap BOF. These items are separate and may not 
> necessarily
> all (or even any) need to be true in the implementation adopted. During the 
> BOF
> there were disagreements on almost all of them.
>
> a. Proposals could be made using the DEP process
>(http://dep.debian.net/deps/dep0/)
>
> b. Goals should have owners.
>
> c. Goals should not be announced unless there's already work going on.
>
> d. There could be a list of goals (with owners and work under way) and a
>wishlist (things that we consider a good idea, but haven't been started).
>
> e. There should be clear tracking of what's going on with each goal.
>
> Additionally, I suggested that a team (be it the TC or some other team) could
> gather the list of goals and once a year let the project vote on it through a
> GR, so that all goals that beat NOTA get approved. This proposal was rejected 
> as
> being too heavy handed.

I like this idea -- it lets every developer have a voice in broad
project goals, which seems better than some small committee. I wonder if
this would let us add a 'not for next release' item in the list, such
that goals above that could be RC?

> My reason for proposing this was that I feel developers will be more engaged
> with the goals if they have voted for them than if they come from an external
> team. However, as long as we are not forcing people to work on specific things
> (i.e. if the bugs related to the goal are not RC), I'm fine with the goals
> coming from whoever the roadmap team is.

Curating the list of goals still needs a committed team to write up a
good description of each goal, and keep things updated as the world
changes. Each goal also needs a discussion on the technical feasibility
of the proposal, a list of dependencies and potential conflicts so that
people can judge the costs and benefits.

> Initally, Mehdi wanted the TC to be the Roadmap team, but given the intent of
> forming this other Roadmap team during the BOF, I don't know what is currently
> expected of the TC.

I think that the work involved in this should be seen as largely
clerical -- collecting goal ideas and writing up coherent
documentation. Some of that requires technical expertise, but I'm not
sure I would like to see such a group actually responsible for choosing
which goals people should be encouraged to work towards.

-- 
-keith


signature.asc
Description: PGP signature

Bug#830344: How should the TC help with a project roadmap?

["Keith Packard"]

Package: tech-ctte
User: tech-c...@packages.debian.org

Mehdi has proposed that the TC be involved in some fashion with a
"project roadmap". Some of the TC members met in person at debconf 16 to
talk about how that might work. I will attempt to (badly) summarize some
of the ideas brought out in that meeting with the goal of encouraging a
more complete discussion here.

I think we had general agreement on a couple of notions:

 1) Work in Debian is done by developers at their own discretion.
 2) We do not want to stop people working on anything

I think that Sam suggested that the TC could help encourage work on
goals which were well specified and already in progress

Keith suggested that the TC could help identify useful goals which were
less well specified and less active.

The end goal of this bug should be a response to the DPL's request.

-- 
-keith


signature.asc
Description: PGP signature

Bug#822803: Call for votes for new TC member

[Keith Packard]

Didier 'OdyX' Raboud  writes:

> [ Unknown signature status ]
> Dear TC members,
>
> I hereby call for votes on the following ballot to fill the vacancy in 
> the TC. The voting period starts now and lasts for up to one week, or 
> until the outcome is no longer in doubt.
>
> ===BEGIN
>
> The Technical Committee recommends that Margarita Manterola  be 
> appointed by the Debian Project Leader to the Technical Committee.
>
> MM: Recommend to appoint Margarita Manterola 
> FD: Further Discussion
>
> ===END

I vote MM > FD

-- 
-keith


signature.asc
Description: PGP signature

Re: Debian Roadmap discussion ?

[Keith Packard]

Didier 'OdyX' Raboud  writes:

> [ Unknown signature status ]
> Dear TC members, dear DPL,
>
> as I have reported to you already, I have had multiple discussions 
> during the course of DebConf so far about the DPL's Debian Roadmap idea 
> with him; and it would make sense for us to get a closer in-person 
> explanation from the DPL to us as he has a vision for a role for the TC 
> there.
>
> What about today @ 18h just after the talks, in the Menzies Café (or 
> around)?

I just scheduled a dinner out this evening and so won't be available at
18:00 today. I've already chatted with Mehdi, so I'm comfortable if you
decide to have the meeting without me.

-- 
-keith


signature.asc
Description: PGP signature

Re: Proposed Summary of 2016-07-03 breakfast meeting

[Keith Packard]

Sam Hartman  writes:

> [ Unknown signature status ]
>
>
> Several members of the TC met after breakfast to discuss planning
> tomorrow's BOF; discussions diverged into general TC issues.

Thanks for writing these notes up; they  seem to capture the salient
points of the meeting well.

-- 
-keith


signature.asc
Description: PGP signature

Re: Meeting to plan ctee bof session

[Keith Packard]

Sam Hartman  writes:

> So, do those of us who are here want to get together possibly tomorrow
> and plan our BOF?
> I am free any time; I don't know others' constraints.

I'm sorry I didn't send mail. I responded in the debconf IRC channel
suggesting that we gather after breakfast this morning at 9:00 as that
appears to not conflict with any scheduled events.

-- 
-keith


signature.asc
Description: PGP signature

Re: Debconf

[Keith Packard]

Sam Hartman  writes:

> It was asked who plans to go to debconf in the meeting today.
> It's my plan to go.

I'm planning on going and have travel approval from $dayjob for the
event.

Looking forward to meeting you there in a few months.

-- 
-keith


signature.asc
Description: PGP signature

Re: Scheduling the next Debian CTTE Meeting

[Keith Packard]

Don Armstrong  writes:

> The 23rd->25th; sorry. I must have been distracted when I was finishing
> that up.

No worries. I voted assuming that was the case.

-- 
-keith


signature.asc
Description: PGP signature

Re: Chair Re-appointment after new membership procedure

[Keith Packard]

Don Armstrong  writes:

> When new members are appointed to the CTTE or within three months of a
> member resigning from the CTTE, the current chairperson should
> announce their intention to vacate the position within two weeks.

Seems reasonable to me.

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: CFV: Debian Menu Systems

[Keith Packard]

I vote:

D>B>A>Z>C

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Keith Packard]

Sam Hartman  writes:

> I ask you to retain the following two paragraphs that explain why we
> prefer option D should we adopt this:
>The Technical Committee has reviewed the underlying technical
>issues around this question and has resolved that Debian will be
>best served by migrating away from our own Debian Menu System and
>towards the common Freedesktop Desktop Entry Specification, and
>that menu information for applications should not be duplicated in
>two different formats.
>
>To encourage this change, we make menu files optional, ask that
>packages include .desktop files as appropriate and prohibit
>packages from providing both menu and .desktop files for the same
>application.

Yes, we would want that as part of any published decision. Thanks for
the clarification.

Do you think the reworded version is easier to understand in the context
of the overall process? That was my major concern here.

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Keith Packard]

Sam Hartman  writes:

> I think a bit.
> My big question is whether you think we'd still be able to call for a
> vote tomorrow if we make this change.

I think the change has real benefit beyond simple clarification by
immediately adopting Charles' changes to policy without waiting for
further changes to that patch.

> So, my recommendation is if you still feel comfortable with me making a
> CFV tomorrow push the change, else do not.

Given that it has the same intent, makes the inspiration for the change
clear *and* means that we'll have the bulk of the policy change adopted
immediately, I think it is worth having the new version and I have
pushed that to the repository.

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Keith Packard]

Sam Hartman  writes:

> OK.
> I'd really appreciate hearing from anyone now who needs more time before
> a CFV.

I'd also love to hear back from Charles about the updated D proposal,
and whether that helps him understand what it means.

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Keith Packard]

Steve Langasek vor...@debian.org writes:

 741573_menu_systems/keithp_draft.txt includes further guidance regarding the
 technical details of how to map between the menu system and .desktop files.
 Since this is not on the ballot itself, how do we intend to surface this so
 that it can be useful to the Policy process?

How about I post that to the bug so it is at least visible?

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Keith Packard]

Charles Plessy ple...@debian.org writes:

 Thanks.  I would appreciate if it would be acknowledged, I am a bit academic 
 by
 training...

The proposed ballot tries to clarify the difference between D and AB by
noting:

   6. The policy change by Charles Plessy in ba679bff76[1]
  would comply with this decision if it were revised to require
  that no package provide a menu file when it provides a .desktop
  file for the same application.

 I have invested a lot of time on AB as I was looking for a compromise that
 would satisfy broady, but as I wrote more recently, I also do not mind a more
 radical outcome.  I would support option D it if we resolve the the point
 below.

We certainly appreciate the work you've done on the existing policy
patch; A, B and D all incorporate that. D goes just a bit further in an
attempt to migrate to the .desktop format

 This is the first half of solving the problem.  The second would be to add 
 that
 the should requirement of the Policy's section 9.6, paragraph 2, is changed
 to may.

Reading from the ballot again:

   2. Packages may provide menu files at the pleasure of the
  maintainer, but packages providing a .desktop file shall not
  also provide a menu file for the same application.

Thinking about this tonight, I've rewritten option D as AB + patch.

As you can see, this makes packages shipping menu and .desktop files for the 
same
application buggy, makes all packages using the Debian Menu System
buggy, and advises that the Debian Menu System be changed to read both
menu and .desktop files.

I think the following version is functionally equivalent to the existing
option D, and makes it clear that we're trying to take your suggestion
and push further in the same direction.

OPTION D':

Using its power under §6.1.1 to decide on any matter of technical
policy, and its power under §6.1.5 to offer advice:

   1. The Technical Committee adopts the changes proposed by Charles
  Plessy in ba679bff[1].

   2. In addition to those changes, the Technical Committee resolves
  that packages providing a .desktop file shall not also provide a
  menu file for the same application.

   3. We further resolve that menu programs should not depend on the
  Debian Menu System and should instead rely on .desktop file
  contents for constructing a list of applications to present to
  the user.

   4. We advise the maintainers of the 'menu' package to update that
  package to reflect this increased focus on .desktop files by
  modifying the 'menu' package to use .desktop files for the
  source of menu information in addition to menu files.

   5. Discussion of the precise relationship between menu file
  section/hints values and .desktop file Categories values may be
  defined within the Debian Menu sub-policy and Debian Menu
  System.

   6. Further modifications to the menu policy are allowed using the
  normal policy modification process.

[1]: 
http://anonscm.debian.org/cgit/dbnpolicy/policy.git/commit/?id=ba679bff76f5b9152f43d5bc901b9b3aad257479

-- 
-keith


signature.asc
Description: PGP signature

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

  * Overall, this would make it possible, therefore, to maintain the
menu information primarily in the more sophisticated .desktop
format, so that source packages with .desktop files would not need
to contain trad menu files too.

Yes, the wording that Sam and I worked out this morning for the final
ballot option advises this kind of solution, where users of the debian
menu system gain access to applications through a combination of menu
and .desktop files.

You can see that draft ballot here:

http://anonscm.debian.org/cgit/collab-maint/debian-ctte.git/tree/741573_menu_systems/odyx_draft.txt

 The only remaining questions are then :
 
  Q1.  Whether it is better to convert from .desktop files to trad
   Debian menu files at package build time, or to change the
   existing trad menu consumers to be able to convert .desktop
   files to the required format ?

I believe that having the debian menu package capable of parsing both
formats will reduce the maintenance burden for packages providing
.desktop files. Someone needs to write a conversion script; adding that
to only the menu package and not all application packages seems like
less work overall.

   There is an easy answer to this: this conversion may involve
   image conversion libraries including even perhaps an SVG
   renderer, and other conversion software, which is
   disproportionately heavyweight for many trad menu consumers.
   (Trad menu consumers tend to be non-desktop `lightweight' window
   managers.)

librsvg2-bin and netpbm are what I use for this work; the dependency
list for these is fairly small, and shares almost everything with
requirements to run a fairly basic X desktop. I do not see this as an
excessive burden to run when installing a new package.

  Q2.  Whether packages (bc, many command line games, ...) which only
   want to provide a trad Debian menu entry should do so by
   including a .desktop file in the source code, or a trad menu
   entry.
 
   I see no need for policy to mandate any particular answer to
   this.  The maintainer should do what they prefer.

The biggest policy change I've proposed is to remove the requirement for
menu files for any package in the archive, and to replace that with a
fairly soft requirement that desktop applications have an associated
.desktop file. Otherwise, maintainers are free to do as they like.

 I think this would involve:

  - defining new field names for .desktop files to contain
the trad menu metadata, as necessary.  I think we can safely
call these fields X-Debian-* or X-Debian-Menu-* or something.

I'd like to suggest that all of this additional menu-package specific
information could be delivered with the menu package itself, and not
spread across all of the application packages. As you note, the bulk of
the information loss in translating .desktop to menu files is in the
hierarchy of the debian menu, and not in information tightly tied to the
specific package version, so the information is unlikely to go stale as
things change. By providing some reasonable defaults for Freedesktop
Desktop Menu categories, the need for per-package definitions would be
greatly reduced.

Yes, this seems a bit backwards, but consider the benefits to menu
system users -- it's probably far easier to convince the menu package
maintainers to release a new version that adjusts the location of a new
application within the debian menu system than to get that application
maintainer to package changes which they are reasonably unlikely to be
dependent on.

And, as the hierarchy is defined by the menu system maintainers, it will
likely be more consistent and correct than having the menu
constructed in distributed fashion by a collection of menu system users
and random desktop application maintainers.

-- 
-keith


signature.asc
Description: PGP signature

Re: Polling open for next CTTE Meeting (and default in future)

[Keith Packard]

Don Armstrong d...@debian.org writes:

 This is a non-binding poll for the default meeting times for future CTTE 
 meetings.

 A: Tuesday 16:00 UTC (April 28th)
 B: Tuesday 17:00 UTC (April 28th)
 C: Tuesday 18:00 UTC (April 28th)
 D: Tuesday 19:00 UTC (April 28th)
 E: Tuesday 20:00 UTC (April 28th)

 F: Wednesday 16:00 UTC (April 29th)
 G: Wednesday 17:00 UTC (April 29th)
 H: Wednesday 18:00 UTC (April 29th)
 I: Wednesday 19:00 UTC (April 29th)
 J: Wednesday 20:00 UTC (April 29th)

 K: Thursday 16:00 UTC (April 30th)
 L: Thursday 17:00 UTC (April 30th)
 M: Thursday 18:00 UTC (April 30th)
 N: Thursday 19:00 UTC (April 30th)
 O: Thursday 20:00 UTC (April 30th)

 Z: Further Discussion

 Please rank times which you cannot attend in general at all below Z.

A = B = F = G = H = I = J = K = L = M = N = O  Z  C = D = E

-- 
-keith


signature.asc
Description: PGP signature

Re: Do we want to submit a sprint request for debconf

[Keith Packard]

Didier 'OdyX' Raboud o...@debian.org writes:

 Ideally, given quorum, we could also take advantage of that time 
 together to push pending issues, and (help) clear our backlog.

While I think this could be done within the bounds of the constitution,
it would eliminate participation from absent TC members and other
people.

So, I think perhaps that we should work on areas of common concern that
are *not* issues formally brought to the TC. I'd still like to see
minutes taken and posted to the list to keep our operations transparent,
even when not enforced by §6.3.3.

I'm certainly open to other suggestions on how to make the best possible
use of this opportunity; it may well be that the whole ctte will be
present at this event.

-- 
-keith


signature.asc
Description: PGP signature

Re: Call for Votes for new CTTE Chairman

[Keith Packard]

Bdale Garbee bd...@gag.com writes:

 === BEGIN

I know my vote isn't necessary to help determine the outcome of the
election, but I felt it would be useful to also record my support for
Don in this role.

A  (B | D)  (E | F | G)  (C | H)

Thanks much to both Bdale (for having served for nearly a decade as
chair), and for Don (for having already done so much for the TC, and now
stepping up to do even more :-)

-- 
-keith


signature.asc
Description: PGP signature

Re: Do we want to submit a sprint request for debconf

[Keith Packard]

Sam Hartman hartm...@debian.org writes:

 A couple of weeks ago I noticed mail to d-d-a talking about sprints at
 debconf.
 I'm wondering whether we want to try and spend a day at debconf or
 debcamp exploring how we want to work together, how we want to resolve
 issues, working on internal procedure, getting to know each other, that
 sort of thing.

I'd be up for an extended meeting and shared meal during debcamp or
debconf. I think it would be useful, both as a way to build camaraderie
and work in our rules of engagement as well as a place to transfer some
experiences in an informal setting from our departing members before
they disappear.

 I'm hoping we've made some progress on some of the above before then,
 but I'm wondering whether:

 1) That time would be useful

I think we'd want to come up with a list of topics and maybe a potential
schedule to get some idea of how much time we think would be useful.

 2) Enough of us will be there to take advantage of it

I'm currently planning on being there, and have funding for travel.

-- 
-keith


signature.asc
Description: PGP signature

Bug#762194: On automatic init system switching on upgrade

[Keith Packard]

Svante Signell svante.sign...@gmail.com writes:

 4. For the moment, we invite concrete proposals for technical changes
which would arrange that 1. new jessie installations using Linux
would get systemd but 2. existing installations retain their
existing init system so far as possible.

 Solutions exists or are in the works for solving this.

I'm aware that people are actively working on this. When a concrete
proposal is ready, we'll be able to consider it. Any resolution before
that would be clouded by uncertainty.

Future software is always bug-free and runs in O(1) time...

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature

Re: [CTTE #746578] libpam-systemd to switch alternate dependency ordering

[Keith Packard]

Anthony Towns a...@erisian.com.au writes:

 ​The tech ctte could've addressed this issue by providing policy guidance
 or by just offering advice, and assuming that the systemd maintainers would
 act on th​e advice or policy in good faith. Choosing to override the
 systemd maintainers was far from the most friendly available option.

If you go back and read the discussion, the participants came to a well
researched and reasoned conclusion that the proposed change was the
correct one in this case.

Here's a paragraph from Josh Triplett's last message before the vote was
taken. Josh is a proponent of systemd, but not a member of the Debian
systemd team.

I don't see any obvious further steps that need to occur other
than flipping the dependency around.  (It might be a good idea
for the libpam-systemd dependency to bump its versioned
dependency on systemd-shim to (= 8-4), but that's up to the
libpam-systemd maintainers.)

I sent a note offering my apologies to the systemd team and to Tollef in
particular for our rash application of an override before we'd given
them a chance to read, review and respond to the conclusions reached by
the discussion participants.

-- 
keith.pack...@intel.com


signature.asc
Description: PGP signature

741573: menu system. Added list of alternative solutions

[Keith Packard]

I've been thinking about how to make progress on 741573, the menu
system bug, and have decided to try and focus our discussion on
constructing a suitable ballot for a vote. I've added a list of
potential ballot items to the repository and hope that we can work on
eliminating as many as possible, and then simply construct a ballot of
the remaining entries and hold a vote.

Here's what I've added:

A suitable edit to §9.6 of the policy manual for each option would be
generated before ballot was written, but I think the wording is
obvious from the contents below:

1)
Require menu
Disallow desktop
2)
Require menu
Allow desktop files
3)
Require none
Allow either
4)
Require one of menu/desktop
Allow other
5)
Allow menu
Require desktop
6)
Disallow menu
Require desktop

This is the current 'keithp_draft.txt'

7)
Refuse to rule
8)
FD


-- 
keith.pack...@intel.com


pgp4gLbUn0W_0.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Ian Jackson writes (Re: Bug#741573: Two menu systems):
 But I'd like to make some specific comments too.  (I'm reading
 24f00b5:741573_menu_systems/keithp_draft.txt, of which I attach a
 copy.)
 ...

 Oh, and:

 Fourthly: It makes no provision for the translation into the new
 regime of the carefully curated organisational structure of the
 existing Debian menus.  Without such a translation it amounts to
 throwing away a lot of work.

I tried to cover this here:

4. Discussion of the precise relationship between menu file
   section/hints values and .desktop file Categories values may be
   defined within the Debian Menu sub-policy and Debian Menu
   System.

I could include a strawman translation between these two sets as a part
of this proposal if you think that would help.

-- 
keith.pack...@intel.com


pgpgA31zu9kfp.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I see Keith has committed a draft to git.  As discussed, I disagree
 with this approach.  This amounts to nonconsensually abolishing
 someone's work when it is still being maintained, and the global cost
 is minimal.

Right, as I said in the May TC meeting, I would draft a proposal that
provided an option which was .desktop-focused. It's not complete yet;
several people have graciously pointed out some fairly obvious bugs.

One of the arguments that I had heard expressed against supporting
applications shipping .desktop files is that it would reduce the number
of applications offered in existing menu packages; I'm hoping that my
draft addresses this question by demonstrating that the .desktop format
offers a proper superset of the information found in menu files, and
that package maintainers could mechanically convert their existing menu
files into .desktop files without loss of information.

 Firstly, there is no talk of a transition plan.  There is AIUI
 currently a mixture of programs which provide both kinds of entry and
 programs which provide only one or only the other.  A resolution
 saying that these things should be unified needs to either contain the
 transition plan, or say that someone (who?) should write it.  If the
 transition plan is to be written later, the resolution should also say
 what should happen in the meantime.

I'm afraid that my notion of a transition plan was expressed implicitly
in the proposal rather than explicitly. In any case, the transition plan
I had in mind was pretty simple:

 1. Implement .desktop parsing support in the existing 'menu' package so
that packages providing only .desktop files would be incorporated
into menu programs without further change.

 2. Transition packages from providing menu files to providing .desktop
files, deprecating support for the menu file format within the
archive over time.

These goals were both expressed in terms of 'should' statements in the
proposal, all of which were to be read in standard terms indicating that
failing to follow these policies would be considered a bug.

It sounds like you'd like to see this transition written in a clearer
and more concrete fashion though.

 Secondly, it doesn't discuss how these menus will be organised or
 displayed.  In particular, it doesn't discuss how to manage the
 distinction between:
   - Menu consumers who want to display a comprehensive menu along
 the lines of the traditional Debian menu;
   - Menu consumers who want to display a curated or filtered menu
 along the lines of the desktop system menus.
 And, of course, the corresponding distinction between the different
 kinds of program.

Right now, the problem we have is that many common menu programs display
only applications which install .desktop files. I don't think that's a
result of careful curating by the menu programs, but rather that the
menu programs end up choosing between the two menu systems, and are often
selecting the one preferred by the upstream menu program developers.

I'd love to see so many programs in my menu that menu program developers
are encouraged to figure out how to reasonably select entries in menus
so that we can get to some kind of intentional preferential listing
mechanism, rather than the ad-hoc selection that we have today.

However, I don't think that Policy is a sound place to make user
interface design decisions, and that we should naturally defer how to
present the provided application set to the menu program developers. I
believe this part of Policy should focus on stating what application
developers are expected to provide for the menu system, and then let the
menu program do 'something sensible' with the provided data.

The freedesktop.org specifications offer some guidance in this area, but
the wide range of potential user interface implementations for
application selection leaves them without a lot of explicit detail.

 At the very least the resolution needs to acknowledge that these
 distinctions exist and say that they are not being abolished.  Or, if
 they are, say which of the two uses is being abolished.

I think this distinction is entirely an artifact of the current split
between packages, some of which install only a menu file, and some of
which install both menu and .desktop files. I would hope that by
encouraging all packages to deliver only .desktop files, we'll see
developers thinking about sensible ways to present hundreds of
applications to their users.

What I'm hearing you say is that you'd like to ensure that users
continue to have an option of seeing all of the programs they've
installed available in a menu system. I'm emphatically agreeing with you
here, to the point where I'm proposing that we make it normal for *all*
menu programs to present all of the installed programs in their menus,
and then encouraging them to figure out how to display them in a
sensible and efficient manner.

 Thirdly, IMO 

Bug#741573: Two menu systems

[Keith Packard]

Colin Watson cjwat...@debian.org writes:

  * There's no reason that has a .desktop file should imply shows up
in modern desktop environments, and so I think that the question of
coverage is to some extent a red herring; the systems have different
coverage because they've always had different coverage, not because
the .desktop format is inherently unable to meet the needs of trad
menu consumers.

That's my view -- the two systems are split because they use a different
file format, and not through any carefully considered reason.

 On the other hand, Keith's draft seems highly aspirational to me.  While
 it seems to me to be broadly the right kind of long-term technical
 direction, there is an awful lot of work in there for people who want
 something like trad menus which is being glossed over.

I think the only piece of work necessary is to add support for .desktop
files to the 'menu' package. With that, other packages are free to
transition from menu files to .desktop files and any existing menu
programs will continue to work as before, while .desktop file consuming
menu programs will slowly see more and more applications to present.

 So, I prefer Ian's position in
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741573#355 for the
 purposes of how the policy text should remain for the time being, and in
 terms of the philosophy of not ripping out work from under people's
 feet.

I guess I'm not sure what work we're ripping out from under people's
feet here. The only significant change proposed is to require support
for .desktop files in the 'menu' package. I would imagine that the
simplest way to add .desktop file support to the 'menu' package would be
to translate .desktop files into menu files and process those through
the existing code base.

 I prefer Keith's position as a long-term direction, but agree
 with Ian that it is lacking an awful lot of transitional thought, and
 feel that it has a lot of things-should-be-done without it being clear
 who will do them.

I feel like there's a mis-characterization of what it would mean to
switch to .desktop files, and whether the change would need to be
all-at-once or could be done incrementally. Here's the transition that I
imagine would occur:

 1) Support for .desktop files is added to the 'menu' package. This
ensures that applications providing only a .desktop file would
continue to appear in menu programs using the existing menu package
infrastructure.

 2) Packages would be encouraged to transition to shipping only .desktop
files. Over time, more and more would start to appear in menu
programs with native .desktop support.

 3) .desktop-based menu program users would start exploring the broader
range of applications shown to them and enjoy the benefits of this
broader selection of tools.

None of these steps places any specific burden on developers, although
skipping step 1) would regress menu programs using menu package support,
dropping any programs which choose to not ship a menu file. I would
expect that to be sufficient incentive for the 'menu' package to add
.desktop file support though.

-- 
keith.pack...@intel.com


pgpfkt8fo4aqZ.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Russ Allbery r...@debian.org writes:

 The counterpoint here, which I had missed earlier in this discussion, is
 the file format for the menus themselves, not the *.desktop files.  I
 agree with you about the *.desktop file format, but the specification for
 the menus is much more complicated.  See:

 http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html

I didn't actually review that spec before putting together my
draft. I think it's slightly orthogonal to the question of how
applications publish information about themselves to a menu program
though.

 I'm not positive that the syntax of /etc/menu-methods is any less complex,
 but it's at least arguable, and it's certainly way different and already
 designed for generating menus for other applications that don't inherently
 support the XDG menu system.

It seems to me that the freedesktop .menu file format is that can be
mechanically constructed from the set of installed .desktop files, at
least by default. To some degree, that makes it something of an
implementation detail for a particular menu program. I think it is
documented so that external menu editing tools can be written to
rearrange things from the default configuration.

-- 
keith.pack...@intel.com


pgpLYZ7LgSb_i.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Josselin Mouette j...@debian.org writes:

 One of the problems I have with your proposal, compared to Charles’
 original patch, is that it encourages maintainers of hundreds of (IMHO
 useless) menu files to port them to the desktop format.

Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:

  All packages that provide applications that need not be passed any
  special command line arguments for normal operations should
  register a menu entry for those applications.

seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.

 We don’t need menu entries for bc or python, unless they are
 NoDisplay=true. This should be obvious, but currently we have trad menu
 entries for them. The proposed wording for the policy (which is the
 result of a compromise work between desktop maintainers and policy
 editors) handles this by stating maintainers must set appropriate
 NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
 are not cooperative in this matter (hence gross hacks such as
 gnome-menus-blacklist).

I think it's a lack of clarity in the spec which encourages
over-production of menu entries.

 Experience shows it doesn’t work. You can have ad-hoc selection after
 time (either automatic or manual), but you need something that works out
 of the box. Three-level nested menus with hundreds of entries are not
 something to present a new user, regardless of her proficiency.

I completely agree, but I don't think we can mandate good UI design in
Policy, all we can do is provide the tools necessary to construct a good
UI.

 There is a sensible way: not present the useless ones. Use
 NoDisplay=true everywhere appropriate.

 I don’t think presenting the whole contents of /usr/bin in a menu is
 helpful in any way to anyone.

As you say, we can't expect package developers to always make the
choices we'd like. I don't have any good solutions here, but I don't
think how the underlying menu information is transmitted in the package
is affected by that problem.

-- 
keith.pack...@intel.com


pgpmwHwIldT7h.pgp
Description: PGP signature

Bug#741573: Two menu systems

[Keith Packard]

Nikolaus Rath nikol...@rath.org writes:

 Keith Packard kei...@keithp.com writes:
  1. Implement .desktop parsing support in the existing 'menu' package so
 that packages providing only .desktop files would be incorporated
 into menu programs without further change.


 FWIW, it seems there is at least partial support for that already. At
 least on my testing system, there is:

 NAME
desktop2menu - create a menu file skeleton from a desktop file

Thanks for pointing that out. desktop2menu is a perl script which uses
the published perl bindings for .desktop files and has a start at a
mapping from .desktop Categories to menu sections. It also doesn't
correctly handle generating .xpm files for the icons.

I think this does demonstrate that we could, with little effort, allow
applications to ship only .desktop files and have the menu package take
those and generate menu files for other systems.

-- 
keith.pack...@intel.com


pgpp8TjiS5W0L.pgp
Description: PGP signature

Re: Scheduling the Next Debian CTTE Meeting

[Keith Packard]

Don Armstrong d...@debian.org writes:

 I don't have a problem with this myself; does anyone have a problem with 

 date -d'Thu May 22 17:00:00 UTC 2014'?

Either date is fine with me; see y'all then.

-- 
keith.pack...@intel.com


pgpZ1Y3eYAo71.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I've done so, thanks.

Looks good.

-- 
keith.pack...@intel.com


pgp6pLZwyhYsw.pgp
Description: PGP signature

Bug#727708: Call for Votes on init system coupling

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I hereby call for votes on my coupling proposal and the amendments
 that have been put.

 The options on the ballot are:

   L   Software may not depend on a specific init system
   N   No TC resolution on this question at this time
   A   Advice: sysvinit compatibility in jessie and multiple init support
   FD  Further discussion

I vote

N  A  FD  L

-- 
keith.pack...@intel.com


pgppE516921Hy.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Perhaps you would like to change this to something like:

The TC chooses to not pass a resolution at the current time
about whether software may require specific init systems.

 I don't formally propose this because I see no point on voting on both
 your proposed wording and this edited one.  But if you like this
 wording, or wish you change it, you may do so, as the proposer of your
 version.

Thanks, yes, this looks better than my original version. Would you like
me to commit the change, or would you like to?

-- 
keith.pack...@intel.com


pgp1qf56IjNHl.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I don't think this is likely but I can see why you would want to try
 that.

Thanks. Being new to the TC, I may feel more reluctant to exercise it's
process than people more familiar to the role.

 And it is different from FD in that if enough people outside the TC
 feel that the issue needs to be decided now, it signals that the time
 for them to propose a GR has come.

While I would lean towards not supporting a GR at this time, I agree
that having one not occur in parallel with a matching TC discussion
would probably work out better.

 And thanks for engaging with the process in a constructive way.

We'll make it work somehow.

-- 
keith.pack...@intel.com


pgpuueAnN6ot_.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 [loose coupling]

Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.

Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.

I agree with you that this is an important issue which needs to be
resolved within the Debian project. I also want to make it clear that I
support the goal of having the project provide a clear policy statement
about this issue in the short term.

The discussions held within the context of the default init bug were
fruitful, and without rancor, which makes me hopeful that the project
membership can drive this issue to consensus in the near future through
the usual policy editing process. As such I'd like to amend this
proposed ballot with an additional option:

 * The TC chooses to not pass a resolution on this issue at the current time.

This is different from FD as it says the TC will not continue
discussions on this issue, although it could well restart them if the
people involved in the policy editing process come to an impasse. It's
also different from 'T' in that it will allow us to revisit this in the
future without needing to overturn a previous decision.

I understand your desire to forestall potential future conflict by
proactively voting this issue, but given the progress already made, I
don't feel like the TC needs to step in now.

Thank you for your consideration.

-- 
keith.pack...@intel.com


pgp3RohzTkwhJ.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Keith Packard]

Russ Allbery r...@debian.org writes:

 The following is technical advice offered to the project by the
 Technical Committee under section 6.1.5 of the constitution.  It does
 not constitute an override of maintainer decisions past or future:

Thanks for making this clear -- operating under §6.1.5 means that this
doesn't conflict with §6.3.6 as it is not a decision.

I remain unsure about how §6.3.5 should inform this process; there's a
fuzzy line between 'advice' and 'design', and I just don't know where
this particular text falls.

I do like the sentiments expressed in the text though, and I hope we'll
see broad consensus form around something akin to it.

-- 
keith.pack...@intel.com


pgpgga2PX63RO.pgp
Description: PGP signature

Re: Understanding the current state

[Keith Packard]

Russ Allbery r...@debian.org writes:

 This is still a live discussion as far as I'm concerned.  There is some
 debate whether this is even something that the TC should be deciding right
 now (Keith, as I recall, expressed that position).

Right, given that the discussions on this list have been generating what
looks like a pretty darn reasonable consensus on this policy work, I'm
hopeful that we'll be able to resolve this without using the Technical
Committee process. This is not to say that the TC members shouldn't be
involved in this work, only that they should be viewed as Debian
contributors rather than in any special TC role.

§6.3.6 says the TC should only be applied when other efforts have
failed. Frankly, it's pretty darn hard to see the current discussions as
'failed' given how much progress has been made.

I'd like to see the existing formal process for changing Debian Policy
followed to conclusion by generating a proposal to change the policy and
bringing that to the Debian Policy Team. If the Debian Policy Team is
unable to come to consensus, I would invite the parties to bring their
issue to the TC for us to look at.

I know I'm new to the TC, so it's just possible I may not understand
precisely what our role should be; I'd love to hear from people who
think my interpretation is inaccurate.

 proceeding too far with that discussion in Ian's absence.

I think we're all willing to wait for Ian to feel comfortable joining
the party again. His views and experience in this area will be
invaluable in developing the right policy here.

-- 
keith.pack...@intel.com


pgpOtp7X2rUUn.pgp
Description: PGP signature

Re: Deposing the chairman of the Technical Committee

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I hereby propose the following TC resolution.

   The Technical Committee has lost confidence in the Committee's
   Chairman and requests that the Chairman resign.

I vote FD above all other options.

-- 
keith.pack...@intel.com


pgp11rEhgHuXQ.pgp
Description: PGP signature

Bug#727708: Init system Call for Votes, Ian's drafts

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I hereby call for votes on my own formal proposal.

I vote FD above all other options.

-- 
keith.pack...@intel.com


pgprr2wx4nVKf.pgp
Description: PGP signature

Bug#727708: Init system coupling call for votes

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I hereby call for votes on the following resolution:

The init system decision is limited to selecting a default
initsystem for jessie.  We expect that Debian will continue to
support multiple init systems for the foreseeable future; we
continue to welcome contributions of support for all init systems.

Therefore, for jessie and later releases, we exercise our power to
set technical policy (Constitution 6.1.1):

Software outside of an init system's implementation may not require
a specific init system to be pid 1, although degraded operation is
tolerable.

Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.

I vote FD above all other options.

-- 
keith.pack...@intel.com


pgp3MSgqexNDM.pgp
Description: PGP signature

Bug#727708: Init system GR override call for votes

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I hereby call for votes on the following resolution

If the project passes (before the release of jessie) by a General
Resolution, a position statement about issues of the day, on the
subject of init systems, the views expressed in that position
statement entirely replace the substance of any TC resolution (past
or future) on the same topic; the TC hereby adopts any such
position statement as its own decision.

Such a position statement could, for example, use these words:

   The Project requests (as a position statement under s4.1.5 of the
   Constitution) that the TC reconsider, and requests that the TC
   would instead decide as follows:

I vote FD above all other options.

-- 
keith.pack...@intel.com


pgpMWBRfnm34D.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Steve Langasek vor...@debian.org writes:

 If the chair ranked them equally in his ballot, why should he express a
 different preference when it comes to the casting vote?

Oh, the obvious answer -- if the chair's preference didn't end up in the
tie, he'd have to explicitly vote from the remaining options.

-- 
keith.pack...@intel.com


pgpQiPLG5GnC1.pgp
Description: PGP signature

Re: call for votes on default Linux init system for jessie

[Keith Packard]

Steve Langasek vor...@debian.org writes:

 I agree with Ian on this.  At this point, it should be clear to everyone
 that, given the stated preferences of each member of the TC, the default
 init system for jessie will be systemd.

Let's finish that vote then and move on.

 But I do not think this is the most important aspect of the problem
 that needs to be decided.  The question of how, or if, multiple init
 systems will coexist in the Debian archive for jessie is what needs to
 be decided in order to unblock maintainers and give them clarity for
 their own packages.

That is an entirely separate issue. I agree that it is important and
needs to be resolved, but the Technical Committee is the wrong place to
be designing this policy. We must (by 6.3.5) not engage in design of new
proposals and policies.

Yes, as individuals, we may choose to collaborate with others on the
development of a suitable policy, and that group may well decide that
they cannot reach a consensus and bring the issue back to the Technical
Committee for advice. Please stop trying to bypass the constitutional
process for policy design.

-- 
keith.pack...@intel.com


pgpSk8XKMt3cv.pgp
Description: PGP signature

Re: call for votes on default Linux init system for jessie

[Keith Packard]

Russ Allbery r...@debian.org writes:

 Well, in defense of the discussion that Steve, Colin, and I have been
 having, I do think it's worthwhile for the TC to try to hammer out a
 compromise on that point as well and express it as either technical advice
 to the project or as technical policy.

I'm really pleased that the three of you have constructed a policy that
looks like a good compromise for this problem. I was worried that this
would also become mired in controversy, when in fact there is already
broad agreement and consensus.

 I also don't think that the approaches that we're discussing at the moment
 involve design work or are at all novel.

It's not sophisticated or novel, but you're definitely crafting new
policy for the project. Given that the group doing this are likely to
reach consensus, it sounds like the Technical Committee process will not
be necessary in this case. And I think we'll all be pleased if that
happens.

-- 
keith.pack...@intel.com


pgpeyr7GFgSnn.pgp
Description: PGP signature

Bug#727708: Call for votes on init system resolution

[Keith Packard]

Russ Allbery r...@debian.org writes:

 I consider the L option as currently written to be a commitment to a
 course of action that is technically broken and unsustainable.  I also
 think the effect of L is contrary to its intended goal and will make it
 less likely, not more likely, that Debian will provide working support for
 any init system other than the default in the long run.  (More on that
 below.)

I agree with this, with a slightly greater emphasis on ensuring that
Debian developers continue to have great latitude in choosing how to
package software. I would also have preferred to continue Bdale's ballot
which didn't mention this issue at all.

I think a fair number of us seem to feel that the T/L notion is at
least as important, if not more important, than the D/U/O/V decision as
it sets a broader and longer-term precedent for the project than
choosing which init system should be the default for jessie.

Would it make sense to actually build a ballot that voted this issue
separately, and do that *before* the default init system for jessie
vote? We would list all four of the proposed versions (nil, L, T and
S).

I don't think guiding the project in this particular area should depend
on which init system was chosen as the default for jessie. I do think
that either you believe that packages should work with any init system,
so that you can separately choose any combination of them, or you
believe that package maintainers should be able to choose a subset of
the available init systems to support, ruling out some combinations.

I readily admit to not really understanding all of the subtleties of our
polling process, but when looking at the votes cast for Ian's proposed
ballot, it looks like we've got a clear set of votes for L vs T already;
each vote places the xL and xT options in the same order for each 'x'.

It seems to me that this issue is clearly a matter of technical policy
and falls under the ctte purview under section 6.1.1, although I believe
it has some ambiguity as to whether it is valid because of 6.3.5. These
options have certainly been proposed and reasonably thoroughly
discussed, although one might not consider the init system bug thread as
separate from the ctte. Of course, it's really a dependency of an issue
which was brought to the ctte, so in a sense, it's a recursive function
call.

-- 
keith.pack...@intel.com


pgphGeaU9EDbb.pgp
Description: PGP signature

Re: Bug#727708: Call for votes on init system resolution

[Keith Packard]

Colin Watson cjwat...@debian.org writes:

 I think I signed my votes when I started on the TC, but then noticed
 that nobody else was doing so and stopped bothering.  I can go back to
 signing them in future, though, since it sounds like it would make some
 people more comfortable.

I just sign all of my email, although I'm using a key that hasn't yet
made it into the debian keyring.

-- 
keith.pack...@intel.com


pgpKzlZxXinF4.pgp
Description: PGP signature

Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.

[Keith Packard]

Sergey B Kirpichev skirpic...@gmail.com writes:

 Are X-people indeed sacrifice portability, or there is something
 different (e.g. these dependencies are optional)?

Speaking as the X server release manager, the systemd patches exist
solely to provide for interoperation with systemd or other similar
device management processes. None of them eliminate existing device
management infrastructure at all.

In effect, X takes the Debian position that patches which improve
interoperabilty with a specific init system should be integrated.

X is most definitely not going to ever require systemd. I think that any
package which requires a specific init system is broken and I'd work to
fix any that I depended on.

 Where is the list of problems for sysvinit we intend to solve?

For X, the problem is running X as a user other than root, which should
provide for increased system security as we'll be reducing the amount of
root code substantially. Using the systemd mechanisms for sending new
input devices to the X server solves one of the longstanding issues with
non-root X.

-- 
keith.pack...@intel.com


pgpa0TJZRUE7y.pgp
Description: PGP signature

Bug#727708: init system resolution - revised proposal

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Ian, Bdale, Andy, Don and Russ agreed on IRC that this was a good
 ballot.  Steve, Colin, Keith: let us know, and perhaps we can start
 the vote sooner.

I can vote with this ballot. Sorry I had to disappear in the middle of
the meeting; that all turned out for naught as the flight I was on got
canceled, and I'll be home for the weekend after all.

-- 
keith.pack...@intel.com


pgpCDqkwKLA2I.pgp
Description: PGP signature

Bug#727708: multiple init systems - formal resolution proposal - Don't like software, don't use it. Absolutely.

[Keith Packard]

Matthias Klumpp matth...@tenstral.net writes:

 Of course it does not exclude implementing that stuff in a different,
 non-systemd tool, but to my knowledge nobody has done that yet.

Exactly so. I have ideas on how this might work in a simpler and more
general fashion, but people rarely listen to ideas without also seeing
working code :-)
-- 

keith.pack...@intel.com


pgp2DPm7AAZV8.pgp
Description: PGP signature

Re: Next CTTE meeting at date -d 'Thu Jan 30 18:00:00 UTC 2014' in #debian-ctte on irc.debian.org

[Keith Packard]

Steve Langasek vor...@debian.org writes:

 On Tue, Jan 28, 2014 at 04:59:10PM -0800, Don Armstrong wrote:
 The next CTTE meeting is at date -d 'Thu Jan 30 18:00:00 UTC 2014' in
 #debian-ctte on irc.debian.org

 FYI, I'm travelling this week and don't believe I'll make it to this
 meeting.

I don't leave for FOSDEM until around 18:30 UTC tomorrow, so I should be
able to make the start of the meeting at least...

-- 
keith.pack...@intel.com


pgp0dA8BGL5dD.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 I think it doesn't make sense to allow people to require a non-default
 init.

I think this position is consistent with allowing each maintainer broad
autonomy, and not overly burdening them with requirements that may make
it difficult or impossible to provide bug fixes and other improvements
From newer upstream versions.

Yes, I'd consider it a bug, but I'm not sure it reaches the level of an
RC bug.

-- 
keith.pack...@intel.com


pgpMPBm_vJZcg.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Bdale Garbee bd...@gag.com writes:

 Thus, I believe the only acceptable option for Q2 from among your set is
 requiring a specific init is permitted even if it is not the default
 one.  But I would prefer to vote a ballot that doesn't mention
 dependencies at all.

I agree with this; I don't think we should try to force developers into
significant work to satisfy an init system constraint as that may
prevent or delay important fixes and improvements from entering the
repository.

Of course, nothing would prevent someone else from fixing these kinds of
bugs and having those fixes get merged into the package, potentially
invoking §6.1.4 to have the tech-ctte resolve any conflict as needed.
However, I'd anticipate that most package developers would readily
accept fixes that made their packages work for more people.

-- 
keith.pack...@intel.com


pgpqxdKZwFmK0.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 If we are I to vote now, I would like to see on the ballot at least:
DM  systemd by default, but also others
DO  systemd only in jessie+1
UM  upstart by default, but also others
UO  upstart only in jessie+1
RM  openrc by default, but also others
VM  sysvinit by default, but also others

I'm still very uncomfortable with any vote that would constrain our
solution space past the Jessie release. I'm fairly convinced that we'll
be supporting multiple init systems for a long time, but my vision gets
very fuzzy out that far, and it's just possible I might be wrong.

-- 
keith.pack...@intel.com


pgpKuKTa8rX3Y.pgp
Description: PGP signature

Bug#727708: call for votes on default Linux init system for jessie

[Keith Packard]

Adrian Bunk b...@stusta.de writes:

   Debian decides that Upstart is the default init system for jessie,
   but it's default desktop GNOME forces the installation of systemd.

There are reasons I've left gnome behind...

-- 
keith.pack...@intel.com


pgpud6GoOLbVe.pgp
Description: PGP signature

Re: call for votes on default Linux init system for jessie

[Keith Packard]

Don Armstrong d...@debian.org writes:

 I think we should break the bigger question into this question plus
 additional advice for transition after we resolve this issue, but for me
 to vote things above FD, we should allow for a simple majority GR to
 vacate this decision.

On one hand, we place great faith in the Debian community to make good
individual and collective decisions about all manner of things, and our
constitution emphasizes the primacy of the individual in almost all
aspects of the project. On the other hand, the ctte is charged by the
constitution to take responsibility to resolve conflicts of precisely
this nature.

Saying that the ctte should be more easily overruled than usual seems to
me as much an abdication of this constitutional responsibility as it
does a wish to empower the broader community with true democratic
powers.

I believe there may be issues of such broad scope and deep impact where
we must ask the whole community to educate themselves sufficiently to
help decide.  What I don't know is if this particular issue reaches that
level.

Don - with your deeper experience in this process, can you help me
understand how this particular issue needs to be handled differently
From previous issues brought to the committee?

-- 
keith.pack...@intel.com


pgpiX2Lk2k6wE.pgp
Description: PGP signature

Bug#727708: Upstart and the CLA

[Keith Packard]

I've been asked by a couple of people for my thoughts on how the upstart
CLA has impacted my position about the default init system for Debian.

I think it's pretty clear the upstart CLA was the most damaging at the
very start of the project. As Kay and Lennart have intimated elsewhere,
the upstart CLA was a very real and important reason for the genesis of
systemd as a separate project instead of a series of improvements for
upstart. Without the upstart CLA, there would be no systemd, and we
would not be discussing which init system to switch to as we would have
all switched to upstart a long time ago.

If the upstart CLA were to disappear today, then future collaboration
would be dramatically eased, and upstart would become a full member of
the free software ecosystem. However, we cannot go back and fix the
damage caused by the CLA at the start of the project. Most of the larger
community has been working hard on systemd since it started and it has
made enormous progress. Upstart has been improving as well, but at a
slower pace commensurate with developer effort.

In my analysis of the proposed replacements as a member of the
tech-ctte, I tried to ignore the political issues (including the CLA)
and focus purely on technical merits of the proposals. What I found was
that both upstart and systemd were a huge improvement over our existing
init system, and that either would be a good move for the Debian project
on Linux. However, on balance, I believe that systemd is a better
replacement for sysvinit than upstart for the majority of Debian uses today.

-- 
keith.pack...@intel.com


pgp1hYDK8otHz.pgp
Description: PGP signature

Re: call for votes on default Linux init system for jessie

[Keith Packard]

Bdale Garbee bd...@gag.com writes:

 Ballot:

   The default init system for Linux architectures in jessie should be

   1.  systemd

   2.  upstart

   3.  openrc

   4.  sysvinit (no change)

   5.  requires further discussion.

I vote 12435

-- 
keith.pack...@intel.com


pgpZ9k37fMjSL.pgp
Description: PGP signature

Bug#727708: init system discussion status

[Keith Packard]

Steve Langasek vor...@debian.org writes:

 I would prefer to see more neutral wording, something to the effect
 of:

I didn't mean that the TC decision should mention the CLA. I don't think
that's an appropriate place for this kind of statement.

-- 
keith.pack...@intel.com


pgpUSSrYvh1Wi.pgp
Description: PGP signature