Add Sep & Oct meetings, as tentative

[debian-ctte.git] / meetings / 20140522 / debian-ctte.2014-05-22-16.58.log.txt

16:58:06 <dondelelcaro> #startmeeting
16:58:06 <MeetBot> Meeting started Thu May 22 16:58:06 2014 UTC.  The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:58:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:58:27 <dondelelcaro> #topic Who is here?
16:58:31 <Diziet> Ian Jackson
16:58:34 <dondelelcaro> Don Armstrong
16:59:05 <dondelelcaro> cjwatson sent his regrets
16:59:05 <bdale> Bdale Garbee
16:59:24 <dondelelcaro> keithp, vorlon: ping; #debian-ctte meeting
17:00:16 <dondelelcaro> waiting just a moment to see if aba, vorlon, or keithp arrive
17:01:34 <dondelelcaro> I'll just continue on, and hopefully they'll wander in
17:01:35 <dondelelcaro> #topic Next Meeting?
17:01:58 <dondelelcaro> currently, the next meeting is scheduled for thursday june 26th at the same time
17:02:02 <dondelelcaro> is that a problem for anyone?
17:02:19 <dondelelcaro> (the meeting after that is for july 31st at the same time)
17:02:48 <bdale> looks ok here for June
17:03:01 <Diziet> I'm fine with the 26th (and the 31st of July for that matter).
17:03:14 <bdale> I can probably do 31 July too
17:03:26 <vorlon> hi
17:03:30 <rra> Sorry I'm late.
17:04:00 <vorlon> june 26, july 31 look ok for me
17:04:09 <dondelelcaro> rra: the next meeting is thursday june 26th; does that work for you? the one after is july 31st
17:04:15 <rra> Yeah, that should be fine.
17:04:23 <dondelelcaro> #agreed next meeting thursday june 26th; meeting after that july 31st
17:04:26 * bdale just sms'ed keithp
17:04:29 <dondelelcaro> #topic #717076 Decide between libjpeg-turbo and libjpeg8 et al.
17:04:46 <dondelelcaro> I think this was just waiting for cjwatson to run it past the secretary
17:04:57 <Diziet> We had a conversation with Kurt.
17:05:12 <Diziet> Kurt hasn't replied to Andreas's comments and IMO he hasn't addressed mine.
17:05:18 <dondelelcaro> OK
17:05:27 <Diziet> I think we should press on.
17:05:31 <dondelelcaro> so do we need to reping secretary@ or just continue?
17:05:32 <Diziet> That is we should vote on our existing issue.
17:05:33 <bdale> keithp will appear shortly
17:05:39 <Diziet> I mean our existing text.
17:05:54 <dondelelcaro> OK; does anyone have a problem with just continuing?
17:06:07 <Diziet> We should preface it with a sentence saying we're using our overlapping jurisdictions power.
17:06:17 <bdale> yes
17:06:17 <Diziet> Then there can be no doubt.
17:06:27 <dondelelcaro> right; sounds good
17:06:41 <Diziet> bdale: Yes to me (you agree) or to Don (you object) ?
17:07:13 <bdale> I agree that we should preface with a sentence about overlapping jurisdictions power
17:07:21 <Diziet> Right.  Good.
17:07:35 <rra> Yeah, that seems right to me as well.
17:07:43 <dondelelcaro> #agreed preface libjpeg text with using overlapping jurisdictions power rationale
17:07:55 <dondelelcaro> #agreed move forward with libjpeg resolution
17:08:07 <dondelelcaro> #action cjwatson to move forward with libjpeg resolution
17:08:14 <dondelelcaro> #topic #636783 constitution: super-majority bug
17:08:36 <Diziet> I sent a series of mails about these things earlier today.
17:09:29 <Diziet> For each one, I guess I need to know: Do people want more time to think/read about this, or do they object, or do they think what I suggest is good ?
17:09:32 <rra> I agree with Diziet's proposal around the super-majority fix.
17:09:32 <keithp> hola!
17:09:38 <Diziet> keithp: Hi.
17:09:55 <rra> I don't feel a need to discuss it further than the discussion that already happened on -project -- I think it's clearly the right thing to do.
17:10:22 <dondelelcaro> Diziet: I think what you're proposing seems good, but I'd have to see the exact wording to know whether I had problems with it
17:10:25 <bdale> I don't like moving the casting vote from TC chair to DPL for the reason Mithrandir states, but as long as the various items aren't too conflated, I'm fine with having a vote on that
17:10:26 <dondelelcaro> Diziet: I agree in principle
17:10:30 <rra> I lean towards agreeing with Diziet about the casting vote, but we might need to talk about that more.
17:10:43 <Diziet> dondelelcaro: OK, good, I'll work on drafting.
17:10:56 <dondelelcaro> #action Diziet to work on drafting super-majority resolution
17:10:58 <dondelelcaro> #topic #636783 constitution: casting vote
17:11:39 <Diziet> I think it's undesirable for one person to effectively have two votes, which is what we have now, with an even-sized committee.
17:12:25 <Diziet> Controversial things often have a mix of political and technical questions so I think input from the DPL is fair enough.
17:12:43 <rra> So, I personally prefer to have close (and therefore probably controversial) decisions somehow tied back to or influenced by the democratic vote of the project as a whole, which is why I like the proposal to have the DPL make the casting vote.
17:12:52 <dondelelcaro> in response to Mithrandir's point, I think that in a case where we've managed to get that split, there's not a pure technical solution, and having the DPL cast isn't bad in that case
17:12:55 <Diziet> Perhaps the right approach for this is for me to simply draft the proposal, and the TC members can vote it up or down.  I'm not sure how fruitful a discussion of the merits will be.
17:12:57 <rra> One of the things that bothers me about the TC is that it's not particularly accountable to the project as a whole.
17:13:00 <bdale> I understand the position, I just don't like the idea that the TC would be rendered incapable of making a decision without outside help
17:13:04 <vorlon> right, so from the bug today, I see the statement "no one has objected to the DPL having the casting vote"
17:13:17 <vorlon> I've just replied - I didn't object because I wasn't aware this had been suggested
17:13:19 <Diziet> vorlon: That was true when I wrote it but is no longer true.
17:13:24 * vorlon nods
17:13:31 <Mithrandir> rra: that should be fixed regardless of the casting vote, IMO.
17:13:35 <Diziet> I think I may have suggested it on IRC.  Obviously it needs to be given more visibility.
17:13:51 <keithp> other similar bodies solve this by having an odd number of members
17:13:57 <rra> Mithrandir: Right, that's the other way to go with it -- find some other way to increase the TC's accountability link to the rest of the project, at which point the motive for this mostly goes away.
17:14:05 <bdale> right, I was about to point out the odd number of members is a better overall solution
17:14:08 <rra> keithp: We need an odd number of voters, not just members, which makes that a bit harder.
17:14:18 <Diziet> OK.
17:14:25 <rra> It's often been the case in the past that not everyone has voted.
17:14:28 <Diziet> Obviously this needs discussion which we should take to email.
17:14:32 <vorlon> but yes, in general I agree it's better to have an odd number of members
17:14:44 <Diziet> I don't think we should try to deal with the merits in detail here.
17:14:57 <dondelelcaro> I'm OK with punting this to e-mail unless someone objects
17:14:59 <keithp> rra: we could count a missing vote as FD over all other?
17:15:12 <bdale> Diziet: right, my implied point is that I find all your emails today on this set of subjects reasonable but I don't personally favor entangling the DPL in TC processes
17:15:15 <vorlon> rra: however, those cases have also not been split down the middle... and getting the last member to vote in such a case is probably a better outcome
17:15:18 <rra> I'm good with going to email.
17:15:37 <rra> vorlon: Yeah, but also this is about the Schwartz set, right?  So even if everyone votes, you can still get a tie because Condorcet.
17:16:08 <Diziet> rra: Pretty unlikely - you have to have pretty contrived situations.  I'm not saying it couldn't happen but it'll be rare.
17:16:30 <bdale> rra: true, but to date I'm only aware of one issue in the history of Debian where the TC has actually been split.  We should make sure such cases are well handled, of course, but I *really* hope that's an experience we never repeat.
17:16:42 <dondelelcaro> #agreed take casting vote discussion to e-mail
17:16:48 <dondelelcaro> #topic #636783 constitution: minimum discussion period
17:16:56 <rra> bdale: Well, yeah, there is that.
17:17:21 <Diziet> I don't know if I mentioned this in email before so perhaps again the suggestion hasn't had the visibility it ought to.
17:17:43 <rra> A minimum discussion period seems like a good idea to me for its own merits, but it introduces a procedural bug if we just do it by itself.  I'm therefore in favor of a minimum discussion period iff we also add a cloture vote.
17:18:29 <Diziet> rra: Um, I think we should discuss this procedural bug by email.  I'm not sure it's as severe as you think.
17:18:29 <keithp> agreed -- minimum discussion period is 'infinite' if there's no way to terminate new motions
17:18:47 <vorlon> my gut reaction is that a cloture vote seems like unnecessary overhead
17:18:50 <Diziet> There's nothing stopping the proposer from not accepting new proposals and then voting.
17:18:54 <bdale> right.  I'm not fond of no-discussion-time vote calling, but there *must* be a way to have a simple up/down vote on an un-conflated question
17:19:16 <vorlon> I don't agree that there must
17:19:19 <Diziet> That is, the min period is only restarted if an amendment is accepted.
17:19:46 <Diziet> If questions are intertangled, then forcing a vote on only part of the question is a procedural abuse.
17:19:49 <vorlon> one member of the TC holding the view that two questions are orthogonal is not a reason for the TC to vote on them separately
17:20:05 <rra> If we vote for cloture, I fail to see procedural abuse.  That's the whole point of cloture.
17:20:24 <rra> It means that the TC has an opportunity to vote on specifically the question of whether two questions are entangled.
17:20:38 <bdale> vorlon: one member holding hte view that they are entangled is likewise not a reason to force an overly complicated ballot
17:20:40 <Diziet> If there is a disagreement about whether the right response is to make a resolution about only one sub-issue, that should be resolved by voting not by preemptive vote-calling.
17:20:55 <Diziet> bdale: It precisely is.
17:21:03 <rra> Basically, that's saying that cloture votes should always lose.  I don't agree with that.
17:21:05 <vorlon> bdale: which brings us to cloture requirements
17:21:08 <dondelelcaro> Diziet: which is what cloture can do
17:21:10 <Diziet> Unless you think we're all incapable of reading and deciding between multiple options.
17:21:29 <bdale> right, this is the heart of the disagreement that was embodied in the init system discussion.  we won't resolve it by further discussion on irc today.
17:21:29 <rra> I think Condorcet breaks down with large numbers of options and a very small voting pool.
17:21:33 <rra> It's not a matter of the voters being dumb.
17:21:33 <Diziet> dondelelcaro: No, there is no need for a preemptive "vote now" if that's what you mean.
17:21:34 <vorlon> (sorry, I meant to say above that my gut reaction was that cloture is unnecessary overhead, but that on reflection it doesn't seem so unnecessary after all)
17:21:37 <rra> It's a system problem.
17:21:43 <Diziet> I'm unfamiliar with the word "cloture" but I guess it means "vote whether to vote now".
17:22:04 <Diziet> I don't think there is any problem with large numbers of options and a small set of voters.
17:22:04 <keithp> Diziet: effectively
17:22:15 <keithp> Diziet: it can lead to tactical voting
17:22:16 <bdale> Diziet: I do
17:22:28 <vorlon> Diziet: yes - "whether to close debate"
17:22:37 <vorlon> see also filibuster, for a pathological case
17:22:39 <bdale> so, there's a valid point here
17:22:45 <Diziet> What the system does ATM is say that the proponent can call for a vote after min-discussion after the last amendment _which they accepted_.
17:22:57 <rra> http://en.wikipedia.org/wiki/Cloture
17:23:07 <bdale> I'm quite ok with a minimum discussion period as long as it's possible to reject proposed amendments
17:23:16 <keithp> Diziet: that gives the proponent a one-vote cloture
17:23:17 <Diziet> If the proponent wants to force a vote, all they have to do is wait for the minimum discussion period, and then call for a vote.  The amendments they didn't accept appear on the ballot.
17:23:24 <bdale> it was unclear to me that such is actually possible
17:23:28 <rra> bdale: Well, reject in the traditional sense, not reject in the Debian voting sense where they end up on the ballot anyway.
17:23:39 <rra> I think Diziet is using reject in the latter sense.
17:23:46 <Diziet> keithp: If the rest of the committee think the vote was premature they can vote FD.
17:23:51 <dondelelcaro> Diziet: the problem is that currently, a single person can cause unrelated amendments to appear on the ballot
17:23:53 <Diziet> rra: Exactly.
17:24:13 <Diziet> dondelelcaro: If the committee thinks those amendments are "unrelated" and spurious, they can just vote against them.
17:24:23 <bdale> dondelelcaro: right.  which is why what I actually care about is that we have some way of having simple up/down votes on simple questions
17:24:33 <Diziet> bdale: I care about exactly the opposite.
17:24:38 <bdale> I know that
17:24:52 <vorlon> the value of a Condorcet voting system is that it allows consensus positions to win
17:24:54 <keithp> bdale: I think the simplest question is whether to close a ballot to further options and take a vote
17:24:59 <vorlon> which is the exact opposite of an up/down vote
17:25:05 <bdale> this is what you and I actually disagree about on a fundamental level.  I'm happy to acknowledge that, and don't think any less of you for it, but I am unlikely to ever agree with you on this point.
17:25:07 <Diziet> vorlon: Quite.
17:25:19 <Diziet> bdale: The constitution was written by me with this very specific intention.
17:25:27 <bdale> I am equally aware of that
17:25:35 <Diziet> You are disagreeing with the whole purpose of the Standard Resolution Procedure.
17:25:37 <dondelelcaro> the problem is that concordecet can also allow consensus options to win which do not resolve the actual question
17:25:46 <rra> Yeah, I'm basically where bdale is at with this.  I totally understand where you're coming from, and it's quite possible that you're right and I'm wrong about this, but it's something I've thought a fair bit about and I'm kind of unlikely to change my mind.
17:25:59 <Diziet> If you want not to follow the spirit as well as the letter of the agreed procedure, you should propose to change the procedure, not act unilaterally.
17:26:03 <vorlon> dondelelcaro: that's a problem only if you assume bad faith on the part of the voters
17:26:20 <bdale> Diziet: I'm happy to talk about changing the procedure, which is what we're doing here I thought?
17:26:40 <Diziet> What I'm trying to do is to write down something that will make it harder to violate the spirit.
17:26:43 <rra> vorlon: The problem is that there's a very strong temptation to do tactical voting in those situations.  I for one was extremely uncomfortable with some of the options that I had and had to explicitly reject.
17:26:46 <vorlon> dondelelcaro: since only members of the committee can propose ballot options, and we are charged with solving problems, proposing a ballot option that solves nothing is surely bad faith
17:27:47 <Diziet> The other reason not to have a system for preventing things being voted on, is that the whole process derives its legitimacy from the votes.
17:28:00 <rra> Well, a cloture vote is still a vote.
17:28:15 <Diziet> Personally I don't think the init system decision was legitimate _because my preferred options were never explicitly voted on and rejected_.
17:29:15 <Diziet> Anyway, the purpose of a "cloture" as described on that WP page is served by the existing process: the proposer can decide to call for a vote.
17:29:23 <rra> I would have preferred to have an explicit cloture vote than have no waiting period, but we didn't have that available as an option.
17:29:54 <rra> Yeah, it's a little different here because in normal parliamentary procedure people can't add more ballot options.
17:30:12 <keithp> rra: agreed; a cloture vote would accept no amendments, and thus would have a finite discussion period before the vote
17:30:16 <dondelelcaro> anyway, I don't think we're going to get unanminity in this discussion here; I suggest we discuss this via e-mail
17:30:24 <rra> Cloture in the US Senate does roughly what we're talking about here, though: it prevents more amendments from being proposed on the bill.
17:30:25 <Diziet> So AFAICT the real disagreement isn't about whether my suggestion of a minimum discussion period would result in an infinite stalling bug.  Since it wouldn't.
17:31:05 <rra> Diziet: No, the debate is over whether we should have a mechanism to prevent any TC member from adding further options to any ballot.
17:31:07 <Diziet> The real disagreement is that those who want to undermine the spirit of the constitution want to continue to do so.
17:31:25 <dondelelcaro> Diziet: that's a bit offensive
17:31:26 <rra> Whatever one might want to call that.  Maybe cloture is the wrong term, but that's the heart of it.
17:31:57 <bdale> I have no interest in "undermining the spirit of the constitution".  I do have an interest in being able to hold votes on individual issues.  [shrug]
17:31:59 <Diziet> I shall try to keep my temper.
17:32:05 <dondelelcaro> Diziet: the fact that we disagree with how we should fix this particular issue does not mean that we're acutally undermining the spirit of the constitution.
17:32:22 <Diziet> dondelelcaro: Please do not contradict my assertion or I will feel the need to justify it.
17:32:57 <Diziet> I guess this might be clear, but I am still absolutely livid, raging furious, etc., about this, even months later.
17:33:00 <dondelelcaro> Diziet: I disagree completely, and I will continue to contradict it. If you feel the need to justify it, go ahead.
17:33:04 <vorlon> I am not concerned about a minimum discussion period causing infinite stalling.  I am concerned that a fixed discussion period that can *only* be reset by proposing new amendments lets votes be called too *easily*, *without* an obligation to work out a consensus position
17:33:04 <bdale> Diziet: when you cast those who disagre with you as "undermining the spirit of the constitution", what outcome do you expect?
17:33:17 <vorlon> as I believe the latter is the real work of the TC
17:33:34 <dondelelcaro> Diziet: I know you are unhappy, but continuing to cast aspersions on the rest of us isn't acceptable.
17:33:54 <keithp> vorlon: so a cloture vote that explicitly terminated discussion at a fixed time would be better?
17:33:57 <rra> Also, speaking as an American who therefore has rather a lot of political experience with spirits of constitutions, I'll say in the abstract that preserving the spirit of a constitution above everything else can be somewhat overrated.  Circumstances do change, and bugs that one didn't notice originally do show up.
17:34:32 <rra> That said, I think it's a good point that we should be very cautious about undermining fundamental assumptions of our governance structure.  I'm not really convinced this would do that, but it's worth thought.
17:34:39 <vorlon> keithp: a cloture vote terminates discussion when there is a consensus that no further discussion is needed - which doesn't happen at a fixed time
17:34:59 <bdale> vorlon: right, to me, the "spirit" here involves words like collaboration and consensus.  what we're talking about, however, are how we handle boundary conditions when those things aren't naturally working right.  I guess it's impossible for this to not be emotional on some level.
17:35:50 <bdale> yeah, cloture isn't really what we're talking about needing here .. it's a concept for breaking a filibuster, which isn't quite the problem we had
17:35:54 <Diziet> I am particularly cross about the way that I clearly set out my intentions, and my understanding of the proper process, and bdale just completely ignored all of that - didn't even disagree with it - and simply did what he wanted to do anyway.
17:35:55 <rra> vorlon: Oh, that's a really good point.  So you're saying, basically, that instead of having a minimum discussion period, we can *only* cut off debate with cloture?  (Which could be taken by voice vote if it's uncontroversial.)
17:36:16 <vorlon> rra: yes, that's my preference
17:36:25 <rra> Hm.  I have to admit I kind of like that.
17:36:34 <Diziet> rra: How would we decide what options would be on the ballot ?
17:36:44 <rra> Yeah, that's a good question.
17:36:49 <Diziet> Since that's actually what the argument was about.
17:36:54 <rra> Right.
17:37:05 <Diziet> Unless you propose to have a meta-vote on each individual amendment on whether to vote on it.
17:37:11 <dondelelcaro> well, every where else except for the CTTE, we have to have seconders for amendments
17:37:14 <bdale> Diziet: I'm sorry you feel that way.  I honestly felt that by laying out a procedural assertion in the way that you did that you left me no other choice.  I hated that.  No you, but being put in that position.  That's why what I'm really trying to focus on here is making sure we can handle such a situation again without having it end up needing to be so emotionally charged for *anyone* involved.
17:37:16 <keithp> oh. that means we could, in theory, call cloture and vote more quickly when necessary
17:37:16 * keithp can imagine times when immediate action is necessary, and a minimum discussion period would make that hard
17:37:17 <rra> Yeah, you're right, cloture is more of a solution to vorlon's problem than to the ballot composition problem.
17:37:42 <rra> keithp: Yeah, exactly.
17:37:45 <Diziet> bdale: If you disagreed with my view on the process, the correct and collegiate thing would have been to discuss it with me.
17:37:49 <dondelelcaro> why don't we just require amendments to the ballot to be seconded by some number of people
17:37:54 <Diziet> To stop and have a "point of order", as it's called.
17:38:09 <Diziet> It wasn't to violate my clearly stated assumptions and go ahead with your own thing.
17:38:27 <Diziet> Indeed it was out to my own sense of propriety that I didn't do to you what you did to me.
17:38:48 <Diziet> dondelelcaro: That would work.
17:38:54 <dondelelcaro> in any event, we have more things on the agenda. Lets take this to e-mail.
17:39:05 <dondelelcaro> #agreed take minimum discussion period to e-mail
17:39:09 <Diziet> In the constitutional category
17:39:11 <dondelelcaro> #topic #681419 Depends: foo | foo-nonfree
17:39:13 <Diziet> I have another one I'm afraid.
17:39:24 <Diziet> Sorry, it was mentioned to me shortly before the meeting.
17:39:38 <Diziet> Someone suggested to me that the tc chairman should be re-elected every few years.
17:40:08 <bdale> I'd be fine with that
17:40:20 <dondelelcaro> OK; lets leave that for additional business at the end, but it's good to think about it
17:40:20 <bdale> the last time we tried something different, we tried a rotation process, and it really just didn't work
17:40:20 <Diziet> Should I put it on my list ?  What period ?
17:40:26 <Diziet> OK.
17:40:28 <Diziet> dondelelcaro: ^
17:40:31 <vorlon> at one time we had a rotating chair; then the music stopped
17:40:46 <rra> So, maybe this is where I should float my radical idea about TC membership to run it past people.  It's kind of unfortunate to bring this up in close proximity to the previous conversation, so let me preface this by saying that it's a general issue of composition of governance bodies, not a reaction to a specific vote.
17:41:09 <dondelelcaro> could we hold off on this until the end when we have the additional business topic?
17:41:09 <rra> It's common in other bodies of this sort to have some mechanism that requires rotating new people through the committee membership.  It keeps people from being "trapped" in a role, and it brings in new perspectives.
17:41:24 <rra> Sure, sorry, I can do that.
17:41:34 <Diziet> So, err, the Depends thing.
17:41:46 <dondelelcaro> I think this is still blocking on vorlon
17:41:50 <vorlon> so I finally got around to posting my follow-up mail
17:41:51 <Diziet> vorlon: Thanks for your message but I'm afraid I didn't get around to reading it properly and writing a response.
17:41:56 <Diziet> So, it's blocking on me I think.
17:41:59 <dondelelcaro> ah, awesome.
17:42:11 <vorlon> Message-ID: <20140424183159.GA1375@virgil.dodds.net>
17:42:34 <vorlon> Diziet: I'm not sure it blocks on you to respond to this, unless someone else actually found it persuasive
17:42:40 <dondelelcaro> OK. so I think once Diziet responds this can go forward?
17:42:41 <vorlon> I haven't seen any follow-ups yet
17:42:48 <dondelelcaro> yeah, I honestly haven't gone through it myself
17:42:49 <bdale> vorlon: where was that sent to?
17:42:58 <bdale> I don't see it in my local email history
17:42:58 <vorlon> IIRC it was cjwatson, rra that were interested in having this written down?
17:43:00 <Diziet> bdale: #681419
17:43:05 <bdale> thanks
17:43:19 <dondelelcaro> bdale: https://lists.debian.org/debian-ctte/2014/04/msg00060.html
17:43:46 <dondelelcaro> #action everyone to read and respond to https://lists.debian.org/debian-ctte/2014/04/msg00060.html if necessary
17:44:02 <dondelelcaro> should we give ourselves a deadline here?
17:44:05 <rra> For what it's worth, I agree with vorlon.
17:44:18 <rra> Having just reviewed that message again.
17:45:19 <Diziet> It hasn't changed my mind.  I should reply to it.
17:45:41 <bdale> I've stated previously that I believe non-default dependencies on non-free are fine, vorlon's note rationalizes that better than I had.
17:45:43 <Diziet> #action Diziet to reply to vorlon re #681419
17:45:56 <Diziet> I'll make my point and then we should vote on it.
17:46:01 <bdale> agreed
17:46:05 <rra> Works here.
17:46:15 <dondelelcaro> ok
17:46:29 <dondelelcaro> #agreed vote on #681419 once Diziet's point is made
17:46:34 <dondelelcaro> #topic #733452 init system readiness protocol
17:46:45 <dondelelcaro> I think this was closed and should be removed from the agenda; is that right?
17:46:47 <Diziet> That's off our agenda; I closed the bug.
17:46:48 <Diziet> Yes.
17:46:50 <dondelelcaro> cool
17:46:58 <dondelelcaro> #agreed close #733452 from agenda
17:47:03 <dondelelcaro> #topic #741573 menu systems and mime-support
17:47:12 <KGB-3> \ f\ 303Ian Jackson\ f \ 305master\ f 61c2ec0 \ 306debian-ctte\ f \ 310meetings/agenda.txt\ f 733452: remove from agenda
17:47:30 <Diziet> JOOI why is mime-support in this topic ?
17:47:38 <bdale> unclear to me too
17:47:56 <rra> The Policy bug was about both.
17:48:11 <rra> I think the mime-support part was uncontroversial; it was just entangled.
17:48:19 <bdale> ok
17:48:24 <dondelelcaro> right; I just kept them both together
17:48:32 <rra> Bill proposed separating it and applying it independently, but I think emotions were running too high for people to be willing to review that.
17:48:35 <bdale> Diziet: I like your latest message on this
17:49:08 <Diziet> rra: If Bill is happy with applying the mime-support part, and it's not technically entangled, it should just be applied and we need say no more about it ?
17:49:21 <rra> Yes, you can ignore it for the purposes of the TC decision, I think.
17:49:30 <bdale> particularly the combination of not chastising a maintainer for not supporting both but making it clear that patches should be accepted
17:50:03 <vorlon> yeah, I'm still of the position that having two menu systems is a policy failure
17:50:18 <Diziet> Is having two MTAs a policy failure ?
17:50:31 <vorlon> and that the idea of them serving different purposes is an illusion
17:50:32 <Diziet> For that matter, two (or n) documentation systems ?
17:50:38 <vorlon> Diziet: two MTAs provide the same interface
17:50:49 <Diziet> vorlon: Two image viewers, then.
17:50:49 <bdale> the "api" to an MTA is standardized so it's not something most packages have to think about, so that's not the same
17:51:09 <dondelelcaro> but having n documentation systems is bad...
17:51:09 <rra> Diziet: Image viewers don't require integration work across the whole archive.
17:51:12 <Diziet> The only reason this has come to us at all is because it is a cross-package thing.
17:51:28 <bdale> dondelelcaro: I agree
17:51:39 <rra> Things every package should ideally do are exactly the most expensive things in a distribution.
17:51:57 <rra> Since they're your local customization and integration cost, directly.
17:52:25 <Diziet> The cost of the menu entries is trivial; there is no interaction with upstream code.  It's hardly more complicated than the control files etc.
17:52:45 <bdale> but it does add checklist items each maintainer must consider
17:52:46 <keithp> Diziet: icons
17:53:00 <rra> It's certainly not as expensive as many other things, but I don't really agree with the idea that the cost is trivial.
17:53:09 <vorlon> Diziet: the actual cost is that we have a system which is less integrated and less well-maintained as a result, because maintainers will *not* universally implement support for both menu systems "as appropriate"
17:53:10 <keithp> generating useful icons in ppm format is hard
17:53:12 <Diziet> It's cheaper than manpages, which we treat similarly.
17:53:14 <rra> I've spent a measurable amount of time on menu entries.
17:53:38 <Diziet> OK, I think we need to stop discussing the merits.
17:53:45 <rra> It is cheaper than man pages, but I think vorlon's point, which was also my perspective, is that we don't require every package provide a man page *and* an info page.
17:53:48 <rra> Which would be similar.
17:53:51 <Diziet> What's the next steps ?  Looks like we may not have consensus on my proposal.
17:54:06 <Diziet> If we don't have consensus then someone who disagrees should write up a counterproposal.
17:54:10 <dondelelcaro> someone should draft a competing proposal
17:54:15 <dondelelcaro> Diziet: exactly
17:54:20 <Diziet> Also, my own proposal needs rra's commentary on para8-10.
17:54:24 <rra> That being said, Diziet's proposal looks really good to me as the "support both" option, and I think is well-written.
17:54:25 <vorlon> I unfortunately don't expect to have time to look at this for a couple of weeks
17:54:32 <Diziet> rra: Do they meet your needs as policy maintainer ?
17:54:34 <rra> Diziet: It looked fine to me.
17:54:34 <bdale> rra: I agree
17:54:37 <Diziet> OK good.
17:54:39 <vorlon> if someone else agrees with me and wants to take a stab at it before then?
17:54:43 <rra> Thank you very much for your work on that.
17:54:53 <bdale> keithp: you interested in drafting the one-system proposal?
17:54:59 <keithp> bdale: yes
17:55:12 <vorlon> \o/
17:55:14 <Diziet> A question for the one-systemers:
17:55:25 <keithp> as bdfl of fd.o, I will draft the fd.o only option
17:55:34 <Diziet> Do you intend to produce a proposal that will continue to expect (eg) bc to provide a menu entry ?
17:55:48 <bdale> bc has a menu entry?
17:55:50 <Diziet> Yes.
17:55:52 <rra> Yes.
17:55:53 <bdale> wow
17:55:56 <keithp> bdale: indeed
17:56:02 <rra> So does tcsh, for that matter.
17:56:08 * bdale can't decide if that's cool, for frightening
17:56:09 <rra> At least the last time I checked.
17:56:10 <Diziet> The fdo menu people think this isn't what menus are for.
17:56:13 <bdale> s/for/or/
17:56:14 <rra> bdale: Exactly.  :)
17:56:21 <keithp> Diziet: fdo menus allow this
17:56:26 <Diziet> keithp: I'm sure they do.
17:56:28 <vorlon> Diziet: yes - there's nothing in the fdo spec that prohibits this, menu entries get categories
17:56:31 <rra> Right, that's the comprehensiveness argument.  Some people really like a comprehensive menu with just about everything in it.
17:56:47 <vorlon> so bc can have a menu entry, and the environment decides whether it's appropriate to be displayed in a particular context
17:56:53 <Diziet> But the people proposing fdo menus in Debian seem mostly to have the opinion that bc shouldn't have a menu entry.
17:56:55 <rra> Diziet: Right, that's not actually an argue in favor of the existing format.  That's an argument in favor of having a way to tag desktop entries so they're not displayed by the DEs by default but people can turn them on.
17:56:59 <rra> Which is not hard.
17:57:04 <Diziet> rra: OK.
17:57:11 <Diziet> I'll take that as a "yes" to my question.
17:57:21 <rra> Er... that's not how I meant it.
17:57:30 <vorlon> Diziet: yes, because most of the people who've been proposing fdo menus are baby-with-the-bathwater reactionaries <sigh>
17:57:44 <rra> I meant it as a "hm, I hadn't thought that through, but maybe we should say that desktop entries should be provided but hidden by default".
17:57:45 <Diziet> rra: So you think bc shouldn't have a menu entry ?
17:57:51 <rra> Oh, wait.
17:57:54 <rra> Ack, sorry.
17:57:58 <Diziet> Right.
17:57:58 <rra> I completely reversed the sense of your question.
17:58:03 <rra> Yes, that's a yes.
17:58:24 <vorlon> ah
17:58:35 <Diziet> OK.  I'll look forward to the draft text and I will probably have something to say about it.
17:58:40 <keithp> Diziet: cool
17:58:55 <Diziet> When the text appears I think I will be able to make more effectively some cogent counterargments.
17:59:12 <vorlon> so I don't think policy should dictate that a particular desktop environment be required to display particular classes of menu entries prominently
17:59:19 <bdale> I look forward to having both positions well articulated, so we can discuss and get to a vote
17:59:22 <Diziet> #action keithp to draft one-menu-system proposal re #741573
17:59:22 <rra> The main thing that using desktop files doesn't provide is the integrations with the various window managers that don't do desktop files, and that's a real functionality loss.
17:59:28 <dondelelcaro> cool
17:59:30 <Mithrandir> (whether bc should have an entry is orthogonal to the menu format question, though.  OnlyShowIn=KitchenSink and then have those DEs that want everything to claim to be KitchenSink.)
17:59:35 <keithp> Diziet: I will draft an fdo-menu only proposal
17:59:49 <Mithrandir> (s/DEs/DEs and WMs/)
17:59:49 <Diziet> keithp: Ta.  I actioned you since you'd already volunteered :-).
17:59:50 <dondelelcaro> #topic #746715 init system fallout
18:00:00 <keithp> Diziet: I was clarifying what I would be writing :-)
18:00:07 <Diziet> keithp: Right :-).
18:00:28 <Diziet> I'm guessing we don't have consensus for my proposed text.
18:00:39 <Diziet> I'm guessing the opponents would prefer "no resolution".
18:00:56 <Diziet> My remaining question is whether there are wording improvements.  (And whether I'm wrong about the other two.)
18:01:20 <rra> Yeah, I'd prefer no resolution, although I have to openly admit that my preference there has been weakened by the fact that the Policy work that I had intended to have done or well underway by now has not happened.
18:01:29 <rra> Which in turn is because my day job has become hell, but that's a long story.
18:01:39 <bdale> I'd rather see this addressed in policy than by TC resolution
18:01:51 <Diziet> OK, that means we don't have consensus as I thought.
18:01:54 <bdale> rra: yeah, sorry to hear that
18:02:00 <Diziet> And it seems we have people who prefer "no resolution"
18:02:38 <rra> (Four reorgs in eight months, two rounds of layoffs, one of which appeared to be political rather than financial... *sigh*)
18:02:38 <Diziet> Does anyone have any suggestions for my text which would improve it and/or make them more likely to vote for it ?
18:03:26 <bdale> text as per your msg of 6 May?
18:03:35 <keithp> bdale: he sent a new version today
18:03:46 <bdale> oh, haven't read that yet I guess
18:03:49 <Diziet> Yes.
18:03:51 <bdale> looking
18:04:04 <Diziet> I reposted it today.
18:04:06 <Diziet> But the text is the same.
18:04:12 <rra> I would be tempted to vote in favor of something that just says "hey, if someone offers you patches for an init system in Debian, please lean towards accepting them unless there's something fundamentally wrong with them."
18:04:16 <keithp> Diziet: I think it's well stated and offers a good summary of what a two-menu system should look like
18:04:26 <Diziet> keithp: We're on the init system fallout now...
18:04:30 <keithp> argh
18:04:31 <keithp> right
18:04:43 <rra> As we've seen in previous discussions, the devil is in the details of wording, and I think Policy is a better place for it, but with Policy not materializing, I do still feel like it's roughly the right thing to say.  It's just a question of who should say it and how.
18:05:06 <bdale> I don't see it .. hrm
18:05:14 <Diziet> rra: The text I'm proposing doesn't tell policy to do or say anything in particular.
18:05:19 <vorlon> one thing about putting this in a TC resolution rather than in policy is that the TC has the authority to make general position statements about principles, whereas for policy we certainly will need to draft policy-appropriate "standards" language
18:05:20 <Diziet> bdale: #746715
18:05:26 <Diziet> vorlon: Indeed.
18:05:35 <Diziet> It's a lot easier for the TC to say something generic and vague.
18:05:52 <rra> Diziet: Right, the wording that you're proposing is close to that.
18:05:57 <vorlon> at least, easier in theory ;)
18:06:00 <bdale> oh, right, Josh posted a long response I haven't read yet either
18:06:34 <vorlon> also, there's a political dimension here
18:07:06 <vorlon> if we actually believe maintainers should make a reasonable effort to continue supporting other init systems, then a TC resolution about it signals this to the broader open source community in a way that a policy edit does not
18:07:07 <Diziet> Josh is complaining that "continue to support" implies something stronger than he likes; personally I think the next sentence makes the meaning clear.  In particular it clearly doesn't require maintainers to build the support themselves.
18:07:13 <rra> Josh's response is basically trying to massage the wording.
18:07:16 <Diziet> vorlon: Good point.
18:08:33 <rra> I think at least some of us are feeling kind of paranoid about what degree of micro-parsing anything we say on this subject will be subjected to, and whether that will then spark more acrimonious threads in debian-devel saying "you're failing to follow the TC ruling!"
18:08:39 <rra> Which feels rather unappealing.
18:09:01 <rra> Which is also why I'm leaning towards saying nothing, since it feels like anything we say is going to be used as a stick for one side to beat the other side with.
18:09:10 <rra> Instead of actually trying to solve problems together.
18:09:13 <Diziet> Um.
18:09:22 <rra> And by sides, I don't mean anyone here.
18:09:38 <Diziet> The statement there is clearly limited to saying something positive but weak for (effectively) non-systemd.
18:09:59 <bdale> I worry about that, but my own concern is more about the distinction between supporting multiple init systems vs caring or not caring for one particular init system
18:10:05 <rra> Right, I know.  I understand what you're trying to do, and I agree with you that what you're saying is what the project should do.
18:10:18 <bdale> sorry, lag, the worry was in regards to rra's point about sticks to beat people with
18:10:18 <rra> In terms of accepting patches if they're in the offing.
18:10:20 <Diziet> If a non-systemd person is using it as a stick to beat a maintainer with, well that will be because the maintainer has failed to "merging reasonable contributions" or is "reverting existing support without a compelling reason" surely.
18:10:43 <rra> Diziet: The problem is that words like "reasonable" and "reverting" are no longer being interpreted in good faith.
18:11:17 <Diziet> What you are saying is that because people are behaving badly, we as the governing body should say nothing lest our words be misinterpreted.
18:11:25 <Diziet> That seems quite backwards.
18:11:38 <Mithrandir> it might just as well be used by a systemd supporter to beat a maintainer who doesn't want to do anything more than sysvinit support with.  I'm not convinced tg would be happy if I gave him patches to do socket activation for CVS.
18:11:44 <Diziet> The answer to misinterpretation is clarification, not silence.
18:11:57 <Diziet> Mithrandir: Heh.
18:12:25 <rra> Diziet: The reason why I thought (and still do think) that Policy would be better for this is that Policy discussions are more organic and do not involve a body in a position of power handing down a ruling.
18:12:33 <vorlon> hmmm, does the current wording suggest that we expect maintainers to take non-upstreamed patches for things like socket activation?
18:12:47 <bdale> it can be read that way
18:12:48 <rra> They feel more democratic and consensus-based and less aggressive, I guess, even when the words we put into the TC ruling are very carefully not aggressive.
18:12:54 <Diziet> rra: Doing this as a TC resolution does not preclude you saying something more definite in policy.  I think the latter would be a jolly good thing.
18:12:59 <Diziet> vorlon: Yes.
18:13:01 <Diziet> It does.
18:13:03 <rra> Oh, sure, I understand.
18:13:07 <vorlon> ah
18:13:22 <Diziet> vorlon: Provided they're "reasonable".  Whatever that means.
18:13:32 <rra> It's possible too that this topic is just going to be a disaster area indefinitely and it doesn't matter whether we say something or nothing.  Which is depressing, but might be more realistic.
18:13:39 <Diziet> If someone has an argument about reasonable then I guess they'll have to come to us agan.
18:13:51 <vorlon> Diziet: but you don't have to enable socket activation to "support" systemd, so that's not how I would have read it
18:14:06 <Diziet> I think that the bad behaviour we are seeing is in part due to a governance vacuum.
18:14:08 <vorlon> I think we as a community should be moving forward towards better init interfaces like socket activation
18:14:29 <vorlon> but I agree that TC rulings shouldn't be used as a stick to try to get us there
18:14:31 <Diziet> vorlon: Uh, I'm not sure I follow.
18:14:39 <rra> Part of the reason why I'm arguing the behavior that I'm arguing is that I do think that, over time, this will all die down.  I'm still seeing people have strong emotional reactions on the basis of very few facts, and I think that will fade.
18:14:47 <bdale> Diziet: by "bad behavior" you mean the one incident in the bug log?
18:14:48 <Diziet> Basically what I was trying to say in my resolution was motherhood and apple pie.
18:14:59 <Diziet> bdale: There have been other more minor irritations.
18:15:10 <bdale> ok.  I'm not aware of those.
18:15:20 <Diziet> And I don't want to pick on the particular maintainer by calling them out as "behaving badly".  Because I don't want to impute bad faith.
18:15:26 <bdale> got it
18:15:42 <dondelelcaro> OK. what is the next step here?
18:15:45 <bdale> what I'm trying to gauge is the magnitude of "the problem" you're trying to address
18:15:45 <Diziet> But Russ is right that there is a lot of heated discussion at the very least.
18:16:05 <Diziet> bdale: Well at least one instance came to the TC.  That normally means that there's dozens we never hear about...
18:16:22 <dondelelcaro> I think we're agreed that we should either issue guidance via the TC or via policy; is that correct?
18:16:24 <Diziet> People don't see coming to the TC as fun, obviously, so it's easier just to shrug and do something else.
18:16:32 <bdale> I wish this were "normal" in so, so many ways.  ;-)
18:16:47 <bdale> dondelelcaro: yes, I think so
18:16:50 <rra> dondelelcaro: I agree with that.
18:17:10 <rra> Providing guidance in Policy was always the intent.
18:17:13 <Diziet> Does passing this TC resolution make issuing a more detailed policy ruling harder ?
18:17:17 <vorlon> bdale: complaints about systemd continue to be one of the hottest areas of discussion on debian-devel, months after the decision was made to switch the default
18:17:19 <Diziet> I don't think so.
18:17:24 <rra> Diziet: I don't think it does.
18:17:46 <Diziet> I think it might help.  And as vorlon says it sends a clear political signal to the wider world.
18:17:46 <rra> Yeah, and sadly those discussions are mostly people sniping at each other.
18:17:54 <bdale> vorlon: I've skimmed some of the threads .. what I've read hasn't led me to the belief that a TC resolution is likely to be helpful
18:17:57 <ansgar> vorlon: I think the systemd discussions on -devel are also the biggest troll attraction currently :/
18:18:22 <bdale> frankly, I think any TC action will just re-invigorate debate
18:18:36 <bdale> no matter how well-reasoned and well-intentioned we are
18:18:37 <vorlon> bdale: I think a lot of the people in those threads are speaking from a position of fear
18:18:45 <Diziet> What vorlon said.
18:18:59 <vorlon> they believe that the change of the default means that everything else will bitrot and there's nothing they can do to prevent it because the project doesn't support them
18:19:13 <Diziet> What is the next step here ?
18:19:17 <rra> Also, some of them think that systemd is going to break everything that they want to do on their system.
18:19:27 <Diziet> bdale: Is there some rewording or rewriting or something that would convince you to support it ?
18:19:33 <vorlon> in that sense, a TC position statement provides an anchor for those who want to work together on non-systemd support
18:19:42 <bdale> para 3 without paras 1 and 2 would be easier for me to support
18:19:50 <vorlon> and gives them an opportunity to engage constructively
18:20:03 <vorlon> instead of, you know, useless tokens like boycottsystemd.org
18:20:21 <Diziet> bdale: I would be happy to replace them with something vague.
18:20:45 * rra starts pondering a conspiracy theory between domain registrars to provoke contentious arguments among technical people in order to sell more domain names.
18:20:59 <Diziet> "The issue of init system support recently came to the Technical Committee's attention again"
18:21:07 <bdale> I'd like to avoid specific mention of upstart, or indeed the specific incident that triggered this discussion, because I think that would re-kindle more flames than it would put out
18:21:14 <bdale> Diziet: that would be better, yes
18:21:25 <Diziet> That plus what is currently para 3.
18:21:28 <vorlon> I'm not sure why that would kindle flames
18:21:40 <rra> That sounds okay here.
18:21:47 <vorlon> I have no beef with the maintainer over his actions here, I don't know why anyone else should
18:22:12 <Diziet> vorlon: Do you feel that the existing para 1+2 are necessary for the resolution's purpose ?
18:22:44 <vorlon> Diziet: I think it's useful to provide context, but I wouldn't say they're necessary
18:23:02 <Diziet> We should provide a link to #746715, but we can do that at the bottom.
18:23:09 <Diziet> Or even outside the formal resolution text.
18:23:09 <vorlon> fine with me
18:23:11 <keithp> Diziet: I think the indirect reference you suggested above is sufficient to provide motivation for the statement
18:23:31 <Diziet> link> Without mentioning its title or anything, I mean.
18:23:36 <dondelelcaro> OK; anything more on this?
18:23:38 <keithp> para 3 is really what we want to say
18:23:38 <Diziet> OK I will redraft.
18:23:39 <bdale> footnote bug linl is good
18:23:44 <Diziet> bdale: OK.
18:23:50 <Diziet> #action Diziet to redraft #746715
18:23:51 <bdale> (sorry, feline in lap making typing hard)
18:24:07 <bdale> 10+kg feline...
18:24:12 * keithp barely escaped cat this morning
18:24:14 <Diziet> #agreed Re #746715 Replace para 1+2 with short intro as discussed
18:24:24 <Diziet> I really need to be going soon...
18:24:29 <bdale> me too
18:24:29 <dondelelcaro> #topic Additional Business
18:24:31 <bdale> very soobn
18:24:36 <Diziet> I think we should postpone our open-ended argument.
18:24:38 <dondelelcaro> OK
18:24:42 <bdale> thanks\
18:24:58 <dondelelcaro> if both Diziet and rra wouldn't mind shoving those agenda items in, we can hit them
18:25:03 <dondelelcaro> next time we meet
18:25:29 <dondelelcaro> anything else?
18:25:33 <rra> To finish my thought from earlier, just so that people can ponder it, it's common in other bodies of this sort to have a rule something like: members serve for two years, and then cannot serve for at least a year before then can be reappointed.  The goal of that is to give more people an opportunity to serve and to rotate through fresh perspectives.
18:25:50 <rra> I have no formal proposal or anything; just wanted to raise it for people to ponder and see what they think of the overall thought.
18:25:54 <KGB-3> \ f\ 303Ian Jackson\ f \ 305master\ f ca4af5b \ 306debian-ctte\ f \ 310meetings/agenda.txt\ f agenda.txt: Add TC elections topic
18:26:12 <Diziet> rra: OK.  Can you put it on the agenda and we can talk about it next time ?
18:26:16 <rra> Will do.
18:26:18 <Diziet> Ta.
18:26:34 <bdale> cool .. both topics are good ones
18:27:03 <bdale> are we done?  I need to leave for a mtg related to the new house...
18:27:14 <dondelelcaro> OK; anything else?
18:27:17 <KGB-3> \ f\ 303Russ Allbery\ f \ 305master\ f cbe2a48 \ 306debian-ctte\ f \ 310meetings/agenda.txt\ f Add TC member rotation to agenda
18:27:25 <dondelelcaro> if not, I'm going to stop here...
18:27:31 <rra> I think we're good.
18:27:35 <dondelelcaro> #endmeeting