18:05:02 <dondelelcaro> #startmeeting
18:05:02 <MeetBot> Meeting started Tue Nov 26 18:05:02 2013 UTC.  The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:05:02 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:05:04 <cjwatson> urgh, wonder how long I can stay
18:05:09 <dondelelcaro> #topic Who is here?
18:05:17 * rra is here.
18:05:17 <dondelelcaro> Don Armstrong
18:05:22 <rra> Russ Allbery
18:05:28 <bdale> Bdale Garbee
18:05:31 <cjwatson> Colin Watson
18:05:32 <dondelelcaro> (sorry I'm lagging a little bit)
18:06:20 <dondelelcaro> aba is commuting home; let me see if I can get Diziet and vorlon
18:07:11 <dondelelcaro> #topic Next Meeting?
18:07:33 <dondelelcaro> currently the next meeting is scheduled for the 26th
18:07:38 <dondelelcaro> which is probably not optimal
18:07:58 <dondelelcaro> I personally don't have a problem with that, but I don't do boxing day, so...
18:08:39 <Diziet> Sorry
18:08:40 <Diziet> Here I am.
18:08:56 <cjwatson> I don't know yet whether I'd be around on the 26th.
18:09:00 <rra> I also don't have a problem with that, but am also happy to have it moved whenever.
18:09:13 <dondelelcaro> cjwatson: any suggestions which would work better?
18:09:32 <dondelelcaro> we could move it up to the 19th if that worked better for people
18:09:44 <Diziet> I would have trouble with this time on the 19th.
18:09:47 <dondelelcaro> ok
18:10:07 <cjwatson> I seem to have, er, put my phone down somewhere so can't get to my calendar right now ...
18:10:17 <Diziet> Keep your calendar in git :-)
18:10:20 <dondelelcaro> heh
18:10:29 <Diziet> "Sorry honey I had a merge conflict"
18:10:30 <cjwatson> Unfortunately I have to interact with the corporate stuff
18:10:46 <cjwatson> So stuck with google calendar
18:11:01 <Diziet> Oddly I can probably manage 26th
18:11:15 <dondelelcaro> OK. lets just stick with the 26th unless someone has a hard conflict
18:11:22 <cjwatson> I'll be at home so the 26th is probably not awful
18:11:27 <dondelelcaro> and we can discuss alternate dates if necessary
18:11:32 <bdale> I'll be traveling from about 20 - 30 Dec
18:11:47 <bdale> may or may not be able to join on 26th, just don't know yet
18:11:53 <dondelelcaro> bdale: OK
18:12:07 <dondelelcaro> why don't I ping the mailing list around the 12th of december and reconfirm the 26th
18:12:12 <rra> That sounds like a plan here.
18:12:17 <bdale> wfm
18:12:21 <Diziet> dondelelcaro: Good plan.
18:12:24 <dondelelcaro> #action dondelelcaro to ping the maliing list at the 12th of december to reconform meeting on the 26th
18:12:29 <dondelelcaro> #topic #717076 Decide between libjpeg-turbo and libjpeg8 et al.
18:12:48 <Diziet> I forget where we're up to with this.
18:13:24 <Diziet> I haven't been following this in total detail but I think I would be ready to vote on it.
18:13:30 <rra> I'm not sure that we've done anything much so far except try to have a conversation about it.  There didn't seem to be much budging.
18:13:38 <dondelelcaro> yeah
18:13:51 <Diziet> No budging> Well, that's what we're here for, isn't it ?
18:13:52 <dondelelcaro> I think we talked about someone writing a resolution
18:13:53 <cjwatson> I'd need to go back and refresh my memory but I seem to remember saying at DebConf that I'd be ready to vote on it.
18:14:03 <cjwatson> I didn't get the impression anyone was likely to budge sans forcing.
18:14:11 <Diziet> So what we need is someone to write up the two options and then we can vote on it.
18:14:20 <rra> libjpeg8 appears to provide some APIs that some of our software needs that aren't otherwise provided.  The rest of the distro world appears to all be moving to libjpeg-turbo.
18:14:21 <dondelelcaro> right
18:14:45 <dondelelcaro> I think the last time we met, Diziet was going to write up the options
18:14:49 <Diziet> Oh...
18:14:56 <Diziet> OK I can do that.
18:14:57 <cjwatson> The missing API AIUI is "decode from memory buffer"
18:15:04 <rra> Yeah, that sounds right.
18:15:07 <bdale> picking -turbo seemed the right answer unless we got further data on libjpeg8, and we haven't, if I recall correctly
18:15:15 <rra> That's where I'm at too.
18:15:18 <dondelelcaro> Diziet To draft resolution asking libjpeg-turbo to make a transition
18:15:19 <dondelelcaro> plan
18:15:21 <cjwatson> And there were some workarounds pointed out
18:15:28 <Diziet> dondelelcaro: So, err, sorry.
18:15:37 <Diziet> #action Diziet to draft resolution asking libjpeg-turbo to make a transition plan
18:15:38 <bdale> I see no value in diverging from rest of the distro world here
18:15:41 <dondelelcaro> right
18:15:57 <dondelelcaro> or at least, not right now, when libjpeg8 doesn't yet embody a standard
18:16:00 <aba> here
18:16:02 <vorlon> erm - doesn't the calendar say the meeting is tomorrow?
18:16:23 <dondelelcaro> vorlon: ergh; it does. I'm all screwed up
18:16:25 <cjwatson> [from the sounds emanating from downstairs I have about two minutes]
18:16:32 <aba> 26th won't do for me btw.
18:16:37 <Diziet> I can't do tomorrow at all.
18:16:39 <dondelelcaro> aba: ok
18:16:51 <Diziet> We should reschedule 26th Dec by email.
18:16:56 <dondelelcaro> OK
18:17:08 * dondelelcaro really shouldn't be setting up these things so horribly
18:17:23 * bdale shrugs
18:17:28 <aba> I also thought it is tonight, but I don't mind either
18:17:28 <Diziet> #action dondelelcaro To canvas opinions and reschedule meeting which would be on 26th Dec
18:17:29 <bdale> a bunch of us are here, I can be here tomorrow too
18:17:33 <bdale> we could continue
18:17:36 <Diziet> We can carry on.
18:17:43 <Diziet> We never really make decisions here, just chase things up.
18:17:46 <dondelelcaro> right
18:17:55 <bdale> right, no voting on IRC anyway
18:18:21 <dondelelcaro> vorlon: hopefully that's OK; sorry for the screwup. I have it in my calendar as today, but the google calendar as tomorrow... :(
18:18:24 <Diziet> Are we done with 717076 ?
18:18:38 <dondelelcaro> yeah
18:18:39 <dondelelcaro> #topic #685795 New ctte member
18:18:45 <dondelelcaro> I think this is just waiting for aba to vote
18:18:48 <Diziet> Yes.
18:18:53 <cjwatson> OK.  I have to go but will accept being chased via scrollback as long as you assign only some reasonable subset of actions to me in my absence :-)
18:18:57 <cjwatson> Sorry
18:19:06 <Diziet> Currently 3 each way, so aba's vote will decide it.
18:19:07 <dondelelcaro> cjwatson: no problem.
18:19:13 <Diziet> cjwatson: :-)
18:19:22 <rra> No pressure, aba.  :)
18:19:23 <vorlon> dondelelcaro: yeah, I'm here now and can stay on :)
18:19:27 <dondelelcaro> #action aba to vote. ;-)
18:19:28 <Diziet> vorlon: Great.
18:19:31 <dondelelcaro> #topic #636783 super-majority conflict;
18:19:45 <Diziet> So, this is stalled on the semi-related overruling advisory GR
18:19:56 <aba> hm?
18:20:05 <Diziet> Because I want to do something like this to get advice from the project.
18:20:17 <Diziet> And I don't want to run us through the GR process on multiple occasions.
18:20:22 <dondelelcaro> Diziet: ok; ISTR that, but just pinging all of the items
18:20:26 <Diziet> Right, yes.
18:20:31 <Diziet> I'm explaining where we are with it.
18:21:03 <Diziet> But I spoke to Bdale and he wasn't happy with the wording but he also didn't think the resolution as proposed would change his approach even if everyone voted yes
18:21:12 <Diziet> I guess the same might be true of some of the rest of you.
18:21:40 <bdale> the part I didn't like was the presumption about why ctte members vote the way they do in the preamble
18:21:47 <Diziet> I'm not sure what the right approach is.  I would like to ask the project a question which will either get me to stop badgering you or get you to do what I want :-)
18:21:58 <Diziet> presumption why> Yes.
18:22:13 <Diziet> But the purpose wouldn't be served unless the resolution addresses the real reasons for reluctance.
18:22:29 <bdale> which you can't know
18:22:36 <bdale> because you're presuming reluctance
18:22:38 <Diziet> Well, we can know what your reasons are.
18:23:05 <Diziet> Well, for example, the n-m thing.
18:23:06 <rra> My primary reluctance about overriding maintainers is that I assume they generally know more about their packaging area than I do, which is not something the GR would particularly change.  I do have a secondary reluctance of worry about social fallout that would probably be changed by the project generally saying "oh, sure, override us, we don't mind."
18:23:23 <vorlon> I also didn't find it something that would affect the way I would vote; I have no problem with the principle of overriding maintainers
18:23:30 <bdale> rra: right, it's the latter that Diziet seemed to be wanting to get confirmation of
18:23:33 <Diziet> Well the people being overridden aren't the same people as who would be voting, is my hypothesis.
18:24:09 <Diziet> If social fallout is a big concern (which I think it may well be) then explicit guidance on that would be helpful.
18:24:14 <bdale> when we talked over dinner at DC, where I *think* we landed was disagreement about what the right thing to do is when we feel at a micro level that one thing is the "best answer" but that decision would have larger consequences
18:24:18 <rra> However, I'm dubious that the project is going to say "oh, sure, override us" when individual maintainers are frequently quite irate about being overridden, plus that's just the natural human tendency.
18:24:51 <Diziet> rra: Well, the reason I keep pushing is because I think there's a majority in the project who would like us to override said irate maintainers more often.
18:25:28 <bdale> I tend to want to balance the micro decision "rightness" with impact on the project at large, Diziet seemed unhappy with my willingness to include non-technical concerns in a supposedly technical question
18:25:32 <Diziet> If we ask that question and the answer is "please don't upset those applecarts" or even "yes fine be held to ransom by toy/pram threats" then I'll stop arguing each time...
18:25:55 <rra> Basically, I guess the summary is that I suppose the GR could change my way of thinking about this at least a little bit, but I'm not sure if it would have a sufficient impact on my voting to really be noticable.  I'd still be inclined to only override if I *both* thought the maintainer was wrong *and* thought the disagreement was actually important.
18:26:06 <bdale> see, there you go again .. saying things like "held ransom" completely colors the discussion
18:26:29 <Diziet> bdale: Sorry.
18:26:34 * Diziet takes a deep breath.
18:26:35 <bdale> rra: right, that's where I fall on this, too.
18:26:41 <vorlon> Diziet: do you think this is an issue in cases where the dispute is actually technical, as opposed to social?
18:27:05 <rra> I'm kind of with Bdale on this, though, insofar as I think it's perfectly natural for people who are working on something for the fun of it to not really enjoy being subjected to more hierarchical decision-making models or having other people tell them what to do.
18:27:13 <aba> vorlon: sometimes the same dispute is social or technical depending on who looks at it
18:27:16 <bdale> Diziet: the problem is that I really do sympathize with your concern.  I'm just not sure that I share it.
18:27:25 <Diziet> I'm not sure what you mean by "the dispute is actually technical", precisely.  It has certainly been the case in multiple situations when we have been asked "what should the contents of the software packages be".
18:27:32 <vorlon> I mean, if there's a technical dispute, I will make sure to inform myself and vote for what I think is technically correct, whether or not that means overriding the maintainer
18:27:33 <aba> rra: the same is true with people paid for it
18:27:54 <vorlon> but for social issues, like deciding who the maintainer of a package should be, the calculus is different
18:28:11 <rra> aba: Sure, but I think to some extent that comes with taking the money (salary, contract, whatever).  You're still annoyed, but oh well, that's why you get paid.
18:28:14 <Diziet> rra: subjected to more hierarchical decision-making models> Well, indeed, but the 3:1 (~4:1) bar is high.
18:28:21 <aba> well, even for "real technical", if I notice both options are almost the same I don't think I'll override someone
18:28:28 <aba> rra: sure
18:28:47 <aba> (but even then, overriding people too often will drive away the good ones)
18:29:03 <vorlon> Diziet: ok, so for cases where we're asked what the contents of the package should be, I regard that as technical and I would vote based on the technical facts - whether or not you have this GR
18:29:03 <Diziet> My view is that not overriding people often enough is driving away good contributors�
18:29:16 <rra> I think that's sort of the heart of Diziet's point: are we overly worried about driving people away and hence not making decisions we should be making.
18:29:35 <Diziet> vorlon: Right.  But I don't think (if we take the n-m thing as an example) that you were one of the reluctant, iirc ?
18:29:44 <Diziet> rra: Yes.
18:29:47 <rra> And that is a thing that happens.  It's easy to not want to irritate the people who get vocally upset and, in the process, irritate the people who just bail rather than getting vocal.
18:29:50 <aba> Diziet: well, that's why one has to decide - to see what's better for debian overall
18:30:11 <vorlon> Diziet: so I don't see the evidence of that, because I don't see the cases that have come before the TC where I think we took a technically inferior decision because of reluctance to override
18:30:46 <rra> I'm not sure it's influenced the decision.  I *do* think it's influenced the timing.  The ones that involve overriding irate maintainers are the ones we tend to sit on for months.
18:31:13 <dondelelcaro> right; we tend to want to make sure that we've got it right before actually taking the vote
18:31:22 <dondelelcaro> which probably ends up irritating everyone
18:31:51 <Diziet> Also our resolutions tend to have a pile of compromise in them.
18:32:27 <vorlon> well, but I think the cause of those compromises is different than you do
18:32:28 <Diziet> Can you all really say that your votes on 688772 would have been identical if you didn't care about the feelings of the maintainers being overruled ?
18:32:37 <bdale> which issue was that?
18:32:41 <vorlon> you seem to be arguing that the compromise is because we're trying to placate the maintainer
18:32:44 * bdale doesn't think in bug numbers
18:32:47 <Diziet> network-manager
18:33:00 <Diziet> vorlon: Well, I guess I'm guessing.
18:33:07 <rra> I guess I'm just sort of dubious that we're going to get any clear guidance from the project on this, as opposed to everyone thinking that we should probably override people who aren't them more than we do.
18:33:08 <vorlon> I think the compromises are because if there were a single, clear-cut, obviously technically correct answer, it wouldn't have come to us in the first place
18:33:19 <bdale> no, I don't think my vote was affected by the feelings of the maintainers being overruled
18:33:52 <vorlon> because, for instance, I don't think the GNOME maintainers are willfully malevolent or stupid, they just perceive the tradeoffs differently because of their position as maintainers of a particular set of packages
18:33:54 <bdale> it *was* affected by the time I spent thinking about how a gnome-centric user might feel
18:33:59 <aba> Diziet: I care about the contributors who would think n-m would be the way to go. independend if they're maintainer of the package or not
18:34:16 <rra> I don't think mine was.  It was an attempt to balance two goals: letting people use a different network configuration with GNOME, versus the tight integration (and therefore loss of features) of using something other than n-m and the significant improvements that have been made in n-m.
18:34:22 <aba> (or gnome-centric view or whatever)
18:35:48 <Diziet> I think this conversation has convinced me that I'm not going to understand your thinking well enough to draft anything coherent, and that it's not clear that there is anything the project could say that would encourage you to respond in a way that would be more like I'm hoping for.
18:36:15 <Diziet> You should perhaps think about whether there is something the project could say that would persaude me to stop being so annoying ...
18:36:50 <Diziet> If you think not then I will just drop this and get on the with the procedural stuff.
18:36:55 <rra> Well, personally I like that you advocate the position that you do, since it makes me think about it and makes me question myself on whether I'm being insufficiently bold for bad reasons.
18:37:04 <rra> I don't have any problem with what you're advocating.
18:37:06 <aba> I don't think you are "so annoying"
18:37:09 <rra> I'm just not always going to agree.  :)
18:37:12 <Diziet> Err, OK, good.
18:37:21 <aba> I think it is actually good to have not all-equal-people here
18:37:26 <Diziet> #action Diziet to drop advisory GR and get on with the rest
18:37:35 <Diziet> Thanks for your kind words :-)
18:37:36 <dondelelcaro> Diziet: I think what you're advocating is more boldness and speed here, and frankly, I think that's in general a good thing
18:37:43 <Diziet> dondelelcaro: Yes.
18:37:47 <vorlon> Diziet: well, I don't think this issue is something I would want to spend the time drafting a GR for - we don't approach TC decisions from exactly the same direction, and that's fine with me
18:38:00 <vorlon> but yeah, being faster to converge on a decision is something I think we can all agree on
18:38:07 <dondelelcaro> Diziet: and I don't know that any of us really want to stand in the way of that; we're just busy and slow.
18:38:15 <vorlon> and I don't think a GR is going to help with that, in practice :)
18:38:20 <Diziet> Yers.
18:38:30 <dondelelcaro> ok; let me move on so we can hit the other things
18:38:33 <Diziet> busy and slow> bad us (including me) but oh well
18:38:35 <Diziet> Yes.
18:38:37 <dondelelcaro> #topic #681419 Depends: foo | foo-nonfree
18:38:48 <Diziet> I bet I have dropped an action here too.
18:38:58 <rra> I think we're waiting on wording here, yes?
18:39:00 <vorlon> so dondelelcaro reminded me of my lingering action item on this, but since I thought the meeting was tomorrow, I haven't followed through yet ;)
18:39:09 <dondelelcaro> yeah,  vorlon to write up response to Diziet about Depends: foo | foo-nonfree
18:39:09 <Diziet> Oh it's vorlon.  Oh good :-).
18:39:12 <dondelelcaro> heh
18:39:25 <dondelelcaro> yeah; lets just get this on the mailing list, and we can continue on. ;-)
18:39:30 <vorlon> I'm gonna try really hard to get that done this week, since I'm on vacation
18:39:41 <dondelelcaro> #topic #719738 lvm2 - Add systemd support
18:39:56 <vorlon> (unfortunately being on vacation means being surrounded by family, so it's hard to get two seconds of quiet in which to think ;)
18:40:02 <dondelelcaro> heh
18:40:24 <vorlon> lvm2> I think I had an action to follow up on that in the public bug
18:40:29 <Diziet> I'm afraid that I found it difficult to see through the angry mails in #719738
18:40:34 <vorlon> unfortunately, events somewhat overtook us
18:41:02 <vorlon> and given that Michael is on break from Debian now, I think it might be best for us to table this now and focus on the default init system question first
18:41:07 <dondelelcaro> OK
18:41:23 <aba> in this case I think we should document that in the bug report?
18:41:26 <rra> Personally, I'm ready to vote on this one, to be honest.  :)  But I'm okay with that course of action.
18:41:37 <Diziet> vorlon: (Don't use the word "table" like that.  In British English it means "to put forward a proposal for discussion".)
18:41:38 <rra> I found the arguments against the provided patch entirely unconvincing.
18:41:45 <bdale> should we pend 719738 on the larger init-system decision?
18:41:54 <bdale> rra: I agree, fwiw
18:41:57 <aba> rra: so you think the patch provided should be applied as-is?
18:42:00 <vorlon> Diziet: yes, yes... :)
18:42:06 <dondelelcaro> rra: I basically don't see why lvm2 shouldn't have support for systemd, but I think the patch as provided makes little sense
18:42:37 <Diziet> I would happily delay this until after the init system vote.
18:42:37 <bdale> so, what's our path forward on this one?
18:42:42 <vorlon> well, I have arguments against the proposed patch, which I would like us to discuss in public
18:42:47 <dondelelcaro> rra: I've no clue why you actually need a generator to do what systemd is signalling lvm2 for, as a single static file should do it
18:42:57 <vorlon> right
18:42:58 <bdale> vorlon: post on mailing list?
18:43:00 <rra> aba: dondelelcaro has a good point.
18:43:01 <Diziet> But I would like to ask both sides to try to be more coherent because atm I don't understand what they're each saying.
18:43:06 <dondelelcaro> right
18:43:09 <dondelelcaro> Diziet: agreed
18:43:26 <vorlon> bdale: zero-sum available time.  Should we concentrate on this now, or on the default init system question?
18:43:50 <dondelelcaro> OK; let me try to get everyone in the bug to explain why the patch has to be done that way, and see if I can get it restarted
18:43:55 <rra> Well, we need to resolve both regardless, but I think the init system discussion is more critical for the project.
18:43:56 <bdale> my preference for sequence is a) add new member, b) decide init-system default, c) deal with the lvm2 question
18:43:58 <aba> then I propose to say we handle that at low priority because we want to prioritize the default init system, but in any case would like lvm2 to work with systemd
18:43:59 <vorlon> oh, I just realized that patch is from the /other/ Michael -oops
18:44:02 <Diziet> dondelelcaro: OK, thanks.
18:44:09 <Diziet> bdale: I agree.
18:44:19 <rra> aba: That sounds right to me.
18:44:20 <dondelelcaro> #action dondelelcaro to get lvm2 patch discussion restarted so when we're done with the other stuff it just happens
18:44:25 <dondelelcaro> #topic #728486 Decide which init system to pick
18:44:26 <Diziet> Thanks.
18:44:40 <dondelelcaro> (I shoved this one last, since I figured it would take all available time)
18:44:47 <vorlon> :-)
18:44:49 <Diziet> So I think we have been all waiting for the new member thing, which I think was sensible, particularly given that the sides were making their pages.
18:44:54 <rra> So, in response to my ping on debian-devel, I got private email from one of the Gentoo folks asking clarification, and they were going to work with zigo to finalize the OpenRC position statement.
18:45:14 <rra> That's the only one left that hasn't been finalized except for the sysvinit one, which has no maintainer.
18:45:15 <vorlon> we ought to set them a deadline
18:45:20 <dondelelcaro> yes
18:45:27 <vorlon> is 1 more week enough?
18:45:38 <Diziet> I would like us to start discussing specifics and asking the sides questions right after we get the new member on board, which ought to be fairly soon after our vote (I assume Lucas will be fine with it - is he going to be around to rubber stamp?)
18:45:49 <aba> btw, the bug# is wrong
18:45:50 <Diziet> vorlon: Yes, I thinkm so.
18:45:53 <rra> I would actually advocate something different: I think the next step is for us to point out the specific things that we think aren't addressed in the existing position statements that might change our minds.
18:46:01 <Diziet> rra: OK
18:46:18 <rra> And I think we can start on that immediately without waiting for the final touches on the OpenRC one, since it will mean modifications.
18:46:20 <bdale> aba: have you voted yet on the new member question?
18:46:21 <vorlon> (personally I don't think openrc is the least bit interesting and I don't think there's anything they could write there that would persuade me, so I'm not inclined to let the decision drag out waiting for them to marshal arguments)
18:46:26 <Diziet> I also want to make sure we all have an idea of what specifically we intend to decide.
18:46:38 <dondelelcaro> right; it's #727708, not #728486
18:46:47 <rra> Diziet: The "something different" was relative to vorlon not to yours, btw.
18:46:52 <aba> bdale: not yet, see mail. But I'll vote on Friday (sorry for being so slow)
18:46:55 <Diziet> It seems to me that we are answering not just the question of "what will be shipped by default in jessie" but also "which init system(s) are packages required to support".
18:46:58 <rra> Yours also sounds fine to me -- the difference is minor.
18:46:59 <bdale> aba: ok
18:47:10 <aba> Diziet: sure
18:47:12 <rra> I think the core of what we're deciding is which init system packages are required to support, yes.
18:47:17 <vorlon> Diziet: I'm not sure I see a reason the new member has to be in before the seated members start asking questions
18:47:18 <rra> (Or which init systems.)
18:47:30 <Diziet> aba: You have until 12:30:13 Z on Friday...
18:47:35 <bdale> Diziet: yes, I think we need to answer both questions
18:47:36 <aba> Diziet: I know.
18:47:45 <rra> "Default" implies "required to support".
18:47:46 <vorlon> rra: from my POV the most important decision that needs to be taken is the default init system for jessie
18:47:49 <aba> (otherwise bdale would need to use his casting vote)
18:47:53 <Diziet> aba: OK, just wanted to be sure you were aware.
18:48:18 <vorlon> right - "default" implies "required to support", but not vice-versa :)
18:48:44 <rra> vorlon: Yeah, I think I'm saying the same thing but just in a weird and backwards way.  Whatever we choose as default is what packages will be required to support, which is the most impactful part of the decision.
18:48:49 <rra> For packagers in general.
18:49:04 <Diziet> rra: Not necessarily.  We could require (in jessie) packages to provide either sysvinit or blibble, and say that blibble will be the default, and packages providing sysvinit will use blibble's syvinit compat mode.
18:49:13 <rra> I suspect we have general consensus that sysvinit will have to be supported in jessie.
18:49:23 <ansgar> rra: Does "support" mean native support? Or also sysvinit compat?
18:49:29 <rra> Diziet: I think providing an init script that works in compat mode qualifies as support regardless.
18:49:31 <dondelelcaro> rra: right; I don't know how we could sanely do the transition without it
18:49:46 <aba> rra: I have the feeling that none of our vendor lockin / general developement diretion questions are answered last I looked?
18:49:49 <Diziet> Or we could even hedge our bets by saying that packages are only required to support sysvinit but say that blibble will be the default.  (I think this would be suboptimal but it's not incoherent.)
18:50:06 <rra> I would even go so far as to say that providing an init script that works in compat mode qualifies as support forever going forward, provided that you really can do everything that the package needs to have done with a compat init script.
18:50:34 <rra> In other words, I see no reason to force packagers to switch to a different format if they don't want to even if we adopt a non-sysvinit solution, *if* the compat mode works for them.
18:50:48 <Diziet> rra: Eventually we may want to declare that bugs which are inevitable consequences of the compat init script design are bugs.
18:50:56 <rra> I suspect that switching will happen naturally just because writing init scripts will be the wall you can stop banging your head against.
18:51:03 <aba> rra: and their scripts are bug-free
18:51:03 <rra> True.
18:51:16 <bdale> rra: how would you expect the case of a blibble maintainer offering a patch to improve blibble support over sysvinit script to be handled?  ie, the lvm2 case'ish
18:51:23 <vorlon> rra, Diziet: it's been pointed out that we could actually allow packages to drop support for sysvinit entirely in jessie, by having a dependency on whichever init system is the new default (to ensure upgrade ordering)
18:51:25 <rra> aba: Well, bugs are bugs and have different severities.  We shouldn't prematurely inflate the severity of bugs.
18:51:44 <vorlon> rra: actually, I thought it was you that pointed this out
18:51:55 <aba> rra: sure. but if the fastest bug is replacing a script by a short file, it will happen more often than not
18:51:56 <rra> Yeah, that's true.
18:52:15 <rra> vorlon: Good point.  We can transition that way.
18:52:36 <aba> bdale: depends if it is required to be supported. Between serious, imporant or wishlist. But of course even patches should be accepted if doing no harm
18:52:49 <dondelelcaro> vorlon: wouldn't that require a reboot in there somewhere?
18:52:54 <vorlon> dondelelcaro: 'telinit u'
18:53:00 <dondelelcaro> ah, right
18:53:01 <rra> Okay, so we don't actually have consensus that sysvinit will have to be supported.  I'd forgotten about that.  thank you for the reminder.  There's that wrinkle that some packages may really want to not deal without cgroups, etc.
18:53:01 <Diziet> Right.  So the upshot is that IMV we can choose from almost the complete set of possibilities from  (choose one init system to be default) x (some monotonic subset of power sets of required init system support matrix for packages)
18:53:31 <dondelelcaro> vorlon: and making sure that the old init script was around while the sevice was restarted... probably workable
18:53:41 <ansgar> vorlon: Does that work for switching? The replacement wouldn't know about statue of running services?
18:53:42 <Diziet> Anyway.
18:53:47 <vorlon> dondelelcaro: yes - udev gives an example of the pathological case
18:53:50 <Diziet> Shall we go back to "next steps"
18:53:54 <dondelelcaro> yeah
18:53:56 <rra> Anyway, I think the next step is to start asking questions or pointing out what we see as the major flaws in particular solutions to give people a chance to address them.
18:54:00 <dondelelcaro> right
18:54:01 <vorlon> ansgar: sysvinit has no concept of running services, so there's no state to migrate
18:54:02 <aba> ansgar: it could be done, but that's a detail
18:54:04 <Diziet> rra: OK, I am happy with that.
18:54:12 <vorlon> this works fine, upstart does it already on upgrade and can reboot cleanly afterwards
18:54:35 <dondelelcaro> #action everyone to start asking questions and pointing out major flaws in next-init-system-question
18:54:39 <ansgar> vorlon: You don't want to start them again if they are already running. And upstart wouldn't know about them runnign when it replaces sysvinit, would it?
18:54:54 <vorlon> any packages that are upgraded after upstart is installed get switched from sysvinit to upstart, so they get service supervision and clean shutdown; any that didn't get upgraded are still handled via sysvinit compat
18:55:12 <bdale> vorlon: so, with neither systemd or upstart currently supporting non-Linux kernels, either sysvinit or openrc would seem to be in-plan for non-Linux systems unless somehow in this process we think we have the power to just axe them, right?
18:55:13 <vorlon> I can't speak to whether systemd does the same kind of graceful handling on upgrade, but it's a solvable problem
18:55:18 <rra> bdale: I think that if we declare a particular init system the default, maintainers should in general lean towards accepting patches that fix bugs in that init system.  In general, though, I really wish maintainers would accept patches to support whatever init system if it doesn't make things worse for other users of the package on other init systems.
18:55:40 <aba> bdale: I think we have the power but the question if it is wise is something else
18:55:42 <vorlon> bdale: well, a) we're the TC so of course we have the power to axe them; b) the kFreeBSD port is making good progress
18:55:43 <rra> There's really no reason for people not to accept upstart or systemd configuration for their packages now if someone has gone to the effort of writing it and will maintain it (the latter, I know, can be an issue).
18:55:48 <Diziet> rra: We could write in policy that patches for better support for other init systems must be accepted.
18:56:21 <aba> Diziet: I consider to write that in the resolution
18:56:26 <rra> Well... hm.  We can write that in our decision, but Policy historically is about the technical contents of the package, not about the social behavior around the package, and that's sort of awkwardly inbetween.
18:57:03 <Diziet> aba: That would be OK by me.
18:57:16 <Diziet> rra: True.
18:57:21 <Diziet> But anyway we can specify it.
18:57:28 <bdale> wording in the TC resolution might suffice?
18:57:31 <Diziet> Yes.
18:57:32 <rra> I will mention that there's some really entertaining possible mixes that may actually make sense.  Like systemd for Linux ports and upstart for non-Linux ports.  :)
18:57:41 <vorlon> haha
18:57:44 <Diziet> rotfl
18:57:45 <bdale> rra: heh
18:57:49 <vorlon> I don't think for a minute that makes sense ;)
18:57:50 <aba> (I think that's already specified by "good behaviour" but writing it up sounds necessary)
18:58:33 <Diziet> If we want packages to support the nonmandatory init systems if the init system maintainers do the work of providing patches, we will certainly have to mandate somewhere that the patches should be taken.
18:58:52 <rra> Grumble.  I mean, you're probably right, but grumble.
18:59:01 <rra> You would think that maintainers would consider that obvious.
18:59:03 <bdale> vorlon: contrary to your earlier assertion, btw, I do find openrc interesting as a possible replacement for sysvinit regardless of what we decide otherwise
18:59:23 <aba> I think they *should* consider that obvious. :)
18:59:41 <aba> bdale: the question is just how relevant that would be for us
18:59:48 <vorlon> bdale: that's fine - in that case if you want to elicit more info from the openrc proponents, be my guest :)
18:59:48 <bdale> unclear
18:59:54 <rra> If we're left in a situation where we have lingering sysvinit, openrc looks a lot more appealing than it to me.
19:00:03 <Diziet> Well, there are downsides to supporting random stuff in a package.  There's a maintenance burden, possible extra bug reports that the maintainer doesn't understand, etc.
19:00:06 <rra> It's certainly a substantial improvement over sysvinit.
19:00:06 <bdale> rra: right
19:00:08 <vorlon> but we seem to be in general agreement to only give the advocates 1 week to finish their position statement
19:00:14 <ansgar> vorlon: What happens if A has a upstart job, you switch from sysvinit to upstart (telinit u), then the event that causes A to start is raised? Do you get two As?
19:00:17 <vorlon> does someone want to take an action to inform them of this?
19:00:25 <Diziet> vorlon: I think we should start asking them questions right away.
19:00:27 <dondelelcaro> #action dondelelcaro to inform advocates of their deadline
19:00:34 <Diziet> Those questions are going to go on for more than a week.
19:00:45 <rra> I'm inclined to agree with Diziet there.
19:00:46 <bdale> I agree, questions now are fine
19:00:51 <vorlon> ansgar: if A has an upstart job on disk before you've switched to upstart?  Yes, in that case it seems you might get two of them (or a failed attempt to start the upstart job)
19:00:58 <dondelelcaro> yeah; questions now, but they basically should have the outline finished in one week
19:01:00 <vorlon> ansgar: thanks, I'll look more closely at this
19:01:10 * vorlon nods
19:01:11 <dondelelcaro> and we can give them a week after the last set of questions to completely answer them
19:01:28 <dondelelcaro> we should try to restrain ourselves to two weeks of questions, too
19:01:29 <bdale> when I specified priorities, my intent was that we have a new member seated before we *vote* on the init system question, no need to delay discussion and/or other parts of getting towards a vote
19:01:36 <Diziet> But maybe we don't guarantee to read anything that's not done in a week and isn't a reply to one of our questions.
19:01:51 <ansgar> vorlon: I think it will get quite hard with corner cases. Personally I don't mind requiring a reboot on upgrade; one has to do so for the new kernel anyway.
19:01:52 <dondelelcaro> Diziet: ah, yes, that's a good point.
19:02:23 <vorlon> btw, I think it's important that TC members have the opportunity to get hands-on experience with both systemd and upstart under Debian
19:02:35 <vorlon> so I was going to set up some VMs and give people access
19:02:36 <rra> I would want to reboot my system if I swapped init implementations.  Supporting that change without a reboot just sounds way too hard to me.
19:02:40 <vorlon> (for both upstart and systemd)
19:02:43 <rra> And it's something I'd do rarely.
19:02:58 * rra is running systemd on the system on which I'm typing this and will be running upstart on another of my home systems shortly.
19:03:03 <Diziet> vorlon: Do you think the systemd maintainers are going to object to the way you have set these vms up ?
19:03:09 <rra> I actually want to update at least one of my packages to support both as well before I vote.
19:03:28 <vorlon> Diziet: I'm going to provide them as stock installs with only the init system changed
19:03:33 <vorlon> Debian unstable
19:03:36 <Diziet> I think these vms are a good idea but I want to be sure not to have a row about it.
19:03:39 <Diziet> vorlon: OK, good.
19:03:52 <vorlon> if the systemd maintainers think this is a poor showing of their package, well...
19:04:21 <vorlon> so that's another thing I'll try to get set up this week during vacation :-)
19:04:34 <dondelelcaro> we're hitting the hour mark; any last minute comments on this?
19:04:38 <aba> vorlon: you have an interessting definition of "vacation"
19:04:55 <rra> Vacation is when you can get done all the things that need to get done instead of all the things that managers think you should so.  :)
19:05:09 <vorlon> aba: it beats watching classic movies all day with my mother-in-law? ;)
19:05:12 <bdale> my definition of vacation is doing something other than what I normally do ...
19:05:15 <vorlon> rra: right! :)
19:05:48 <dondelelcaro> #topic Additional Business
19:05:56 <bdale> aba: so, please, vote on the new member question before the vote deadline .. I'd prefer we all vote than other processes be invoked
19:06:05 <aba> bdale: I'll do.
19:06:15 <dondelelcaro> anything else?
19:06:28 <vorlon> not from me
19:06:33 <aba> (I could vote 113 of course)
19:06:37 <dondelelcaro> heh
19:07:01 <rra> Nothing here.  Work has finally calmed down a bit, so I should be more active.
19:07:10 <bdale> aba: sadly, my stinky trout launcher was lost in the fire .. but I'm sure I could come up with something if I have to!
19:07:52 <bdale> nothing else here
19:07:55 <dondelelcaro> OK; stoping here.
19:07:58 <dondelelcaro> #endmeeting