--- /dev/null
+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
\ No newline at end of file
projects / debian-ctte.git / commitdiff