17:00:15 #startmeeting 17:00:15 Meeting started Thu Oct 30 17:00:15 2014 UTC. The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:17 #topic Who is here? 17:00:19 Don Armstrong 17:00:23 Ian Jackson 17:00:23 Russ Allbery 17:00:53 vorlon (Steve) sends in his semi-regrets 17:00:54 Colin Watson 17:01:26 bdale, keithp, aba: ping 17:02:26 those three are long-time idle, so I'll just continue on 17:02:35 #topic Next Meeting? 17:03:33 currently this is Thursday the 27th at 18:00 UTC iirc. 17:03:42 Works for me 17:03:54 unfortunately, I will probably be in a location with really bad internet, so I might not be available 17:04:06 sorry for being a few minutes late 17:04:17 but I should know that week; someone should just take over for me and run the meeting 17:04:33 Would the previous or the next week be better for you ? 17:05:07 I'm probably unavailable the previous week 17:05:15 Though the next week works too 17:05:18 the next week would, but unless lots of people have trouble with thanksgiving, we might as well just work it 17:05:36 does anyone have a problem with moving that back one week? 17:06:00 not me 17:06:15 Fine by me 17:06:23 Fine by me 17:06:32 #action dondelelcaro to tentatively move next meeting back a week, and ask on -ctte if anyone else has a problem 17:06:43 #topic #636783 constitution: super-majority bug 17:07:01 Can we put the constitutional stuff to the back of the queue given the release timing and everything else ? 17:07:10 sure 17:07:20 Yeah, the week before would be better for me -- I'll have company over Thanksgiving. (Sorry, people talking to me.) 17:07:26 topic #681419 Depends: foo | foo-nonfree 17:07:33 #topic #681419 Depends: foo | foo-nonfree 17:07:46 I just need to finalize this 17:07:52 #action dondelelcaro to finalize #681419 17:08:01 #topic #741573 menu systems and mime-support 17:08:19 I think keithp wrote up the start of the ballot for this already 17:08:26 I have to say I'm not convinced by Keith's categorisation. 17:08:51 "Require" might mean lots of different things. 17:09:02 Diziet: I promised to write up one more position and haven't gotten to that yet 17:09:30 * bdale just got online 17:09:37 at LF BOD in-person meeting today 17:09:38 #action keithp to write up one more position for #741573 17:09:59 too much travel in my life 17:10:11 categorisation> I mean as found in keithp_alternatives.txt eg 17:10:57 OK. Do we have anything else for this bug? 17:11:23 #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades 17:11:24 not from me 17:11:26 Diziet: which is why I promised to write up the middle position more completely 17:11:49 I think the next three topics are really kind of all the same; is that a correct characterization? 17:12:03 #765803 Ask before changing init system when upgrading to jessie and Inform about init systems when installing jessie 17:12:11 #746578 libpam-systemd: for upgrade safety, swap or-dependency to systemd-shim|systemd-sysv 17:12:14 for reference 17:12:27 The last is somewhat different, but it probably makes sense to discuss them all together. 17:12:28 765803 and 762194 are the same 17:12:28 they certainly could all fall in to one discussion bucket from my perspective 17:12:40 746578 is a detail which depends on the former 17:13:02 right 17:13:13 let me just merge #765803 and #762194 17:13:13 I would like to get to a vote about 762194/765803 (switching existing systems) ASAP. 17:13:26 I can't imagine there can be much more to be said about the principle of the question. 17:13:38 I'm feeling generally uncomfortable about changing init systems on dist-upgrade. I think we went through two release cycles with dependency-based boot IIRC; it was optional and then it became automatic. 17:13:40 as I indicated in email, I think voting on those while the GR is in process isn't clearly a good idea 17:13:44 And at this stage of the release it is still possible to make a decision on this without making too much disruption. 17:14:02 bdale: The GR is going to be another 3 weeks. 17:14:05 However, I would feel a lot more comfortable voting to not change init systems on upgrade if someone had a fairly complete proposal for exactly what dependencies between various packages they propose. 17:14:09 We should decide on the automatic switch before then IMO 17:14:19 I don't think this is trivial, and it would be nice to have a fleshed alternative that someone has actually tested. 17:14:45 As Tollef pointed out, it's important to get the right behavior between the various ways of bootstrapping a new Debian install. 17:14:54 Diziet: I'd have been happy to act on this sooner if the GR were not already in process 17:15:00 At the moment the dependencies we have have known serious bugs, which is that your init system can be swapped if you install some packages. 17:15:30 I don't think it's reasonable to say that we need a tested alternative given how bad the situation is right now. 17:15:46 Well, then I'm unreasonable. *shrug* 17:15:57 The current situation worked trivially and reliably for me. 17:16:01 Diziet: I think it's unclear that it is a serious bug if there is an open GR on that topic. 17:16:02 if we don't have a tested alternative, it's not clear to me what we'd actually be mandating maintainers to do 17:16:18 without some sort of tested alternative to vote on, all we're going to be doing if we vote is to apply "stop energy", right? 17:16:35 rra: Have you seen the reports of switching inits as a result of package installations ? 17:16:48 Diziet: Yes, we're switching init systems on dist-upgrade right now. 17:16:57 bdale: The detailed implementation is AIUI mostly 746578 17:16:57 I know that. That's the whole point of the bug. :) 17:16:59 fwiw I remain unpersuaded that we should try to avoid switching init on upgrade 17:17:05 (hi, work meeting deferred) 17:17:16 rra: No, I mean, if you are running jessie and say apt-get install blatherwossname, you might find that your init is changed. 17:17:26 Diziet: Yes, that's a special case of dist-upgrade. 17:17:43 It's all part of the same dependency structure. 17:17:51 Forget about what it's a special case of. It's surely not desirable. 17:18:00 I'm as yet undecided regarding switching init on upgrade, but switching on leaf package installations suggests to me that something is excessively fragile and needs attention 17:18:01 If we're going to switch init systems on dist-upgrade, that necessarily implies we're switching init systems for particular package upgrades. 17:18:18 This is true, but those particular packages should be deep in the stack, not some random daemon 17:18:19 rra: A good reason not to do the former! 17:18:43 (I don't know the details of this, but I'm inferring from Diziet's use of metasyntactic variables that they aren't particularly intrinsically important packages) 17:18:46 Diziet: I think this is why having this discussion while the GR is pending is not useful 17:18:51 I will say that the feedback I'm getting from people outside of Debian, including people who are actually fairly fond of systemd in the abstract, is that having the init system change on dist-upgrade is very undesirable. 17:18:56 cjwatson: You're right. They're applications, in the reports I've seen. 17:19:02 the thing I wouldn't want is for my init system to be changed out without having some chance to say "stop that!" 17:19:08 There are a lot of people with customized init scripts and other hacks that will need to be reworked during the switch. 17:19:14 bdale: That's exactly what's happening right now. 17:19:19 on the other hand, I'm routinely careful about dist-upgrades for exactly that reason 17:19:23 This was also the case with dependency-based boot, but in that case we could detect the problems. Here, we can't easily. 17:19:39 Diziet: I know, but I don't think the "fix" is to require that it not happen, I think the fix is to ensure the user knows it's about to happen 17:19:45 my problem with this particular issue is we don't currently have a set of changes which need to be made now, with a set of patches which are tested 17:19:52 Diziet, cjwatson: That's a good point -- I think what I'm driving at is that if we decide not to change init systems on dist-upgrade, that all goes way anyway. 17:19:58 dondelelcaro++ 17:19:58 The dependency based boot wasn't done at the level of installing different packages. So it could degrade to a non-dependency-based approach when it detected problems. 17:20:11 rra: We certainly have common ground there 17:20:21 I think we're mostly agreed that switching randomly is bad, but no one has yet done the work to actually outline a solution to this 17:20:25 dondelelcaro: We have the swap dependency patch, which is at the very least a dramatic improvement. 17:20:45 Diziet: right, but I think that's just one small part of the whole issue 17:20:49 Are you really saying that we shouldn't make that change because we don't know for sure that the result is perfect ? 17:20:54 Tollef seems happier with systemd-shim since the removal of the cloned-and-hacked dbus policy 17:20:55 Diziet: no. 17:20:58 (AIUI) 17:21:03 I think the dependencies on libpam-systemd should be swapped regardless; I haven't yet seen a good reason not to do that. 17:21:11 Diziet: I'm saying that unless the only change is the libpam-systemd change, I don't know what else is being proposed 17:21:17 Maybe I'm missing something, but if so, someone should explain it to me. :) 17:21:26 Yeah, there were formerly some defensible reasons, but they seem to have been dealt with 17:21:45 rra: OK. 17:21:51 rra: I think all potential issues with having systemd-shim|systemd-sysv are dealt with. 17:22:00 Can we say something like "swapping init as a result of leaf packages is not desirable" 17:22:03 is there anyone who disagrees with the libpam-systemd dependency swap? 17:22:20 Diziet: That conflicts with the GR options doesn't it? 17:22:45 Diziet: If the GR that says packages can freely depend on a specific init system wins, that contradicts that decision. 17:22:50 And something like "our decision in February was not intended as a mandate to swap init system on upgrades" 17:22:55 and, if there's no one who disagrees, is there anyone who disagrees with at least getting a ballot written up to do that override? (libpam-systemd) 17:23:07 I would really rather not pass a TC decision right now that contradicts one of the GR ballot options. 17:23:12 Down that path lies constitutional madness. 17:23:23 dondelelcaro: I'm not sure you still need an override for that. 17:23:28 rra: How about we put it as a tentative piece of advice, or something. 17:23:34 I'm sure we can fix that with wording. 17:23:35 ansgar: well, if we decide it, we're going to override the maintainer. 17:23:39 dondelelcaro: I'm in favor of that assuming that we need to decide things at all. 17:23:44 I don't see a reason not to prepare it and start discussing, at least 17:23:59 I haven't seen anyone suggest we shouldn't just overrule. 17:24:10 Diziet: I would rather see a concrete proposal for what dependencies should be changed. 17:24:18 me too 17:24:23 ok; at least in this bit, I think we can make headway without deciding everything else 17:24:25 rra: 746578 has a concrete proposal 17:24:26 Rather than just saying something vague like saying no leaf packages should result in init system changes. 17:24:43 #agreed libpam-systemd to flip dependencies 17:24:43 I will write something up which I think has half a chance of you agreeing with it. 17:24:55 If you disagree with the specific wording please let me know. 17:25:05 #action Diziet to draft resolution on #746578 17:25:13 works for me 17:25:14 Diziet: 746578 is the libpam-systemd dependencies, isn't it? 17:25:18 rra: right 17:25:19 I'm fine with deciding that now. 17:25:22 rra: Yes. 17:25:25 Good. 17:25:26 I think we're actually in agreement there. 17:25:36 And I think that's orthogonal to the GR. 17:25:42 And indeed, it has a concrete proposal. 17:25:57 That's what I meant. 17:26:05 Ah, okay, we're on the same page then. 17:26:10 dondelelcaro: Well, I mean the systemd maintainers weren't too opposed to it with the last changes (IIRC). 17:26:14 One reason swapping it was opposed is that it was necessary to ensure the swap-on-upgrade 17:26:29 I think Steve analyzed the dependency tree and found that wasn't the case, didn't he? 17:26:36 I think given the rest of the comments we have to punt on the wider question 17:26:58 Or: 17:27:06 ansgar: *shrug*; if they've already flipped it by the time we decide, great. 17:27:24 I continue to be fine with passing a simple GR saying that our decision in February was not intended to imply any position on whether init should be changed during upgrade. 17:27:33 I don't know if that's helpful or not, but it would be fine with me to say that, since it's true. 17:27:40 How about this: "We aren't convinced we want to swap on upgrades and we invite submissions of a concrete set of technical changes to ensure that existing machines keep their existing inits, while new Linux installations get systemd" 17:27:41 there was a statement from one of the systemd maintainers (mbiebl, I think?) that he wanted admins to have to explicitly make the choice of systemd-shim over systemd-sysv, separately from choosing sysvinit over systemd-sysv 17:27:42 Er, not a GR. 17:27:45 A simple TC decision. 17:27:54 rra: Right. 17:27:56 Good. 17:28:07 I certainly disagree with that 17:28:18 vorlon: Ah, yes, I remember that. But I don't think that makes sense. At least, I don't understand what the point would be. 17:28:29 vorlon: You think our decision in February was intended to imply a change on upgrade ? 17:28:31 Taking a step back, I expect us to have two supported configurations for logind in jessie. 17:28:35 1) systemd-sysv. 17:28:41 2) sysvinit-core plus systemd-shim. 17:28:49 rra: right; so unless someone marshalls an argument that he finds persuasive, this seems to be a matter for TC override of a maintainer 17:29:03 I don't see where people have two real choices. Either they're using systemd, or they're using sysvinit-core and will need systemd-shim if they need logind. 17:29:26 I think we're on agreement on that. 17:29:30 Diziet: sorry, I don't understand how that question is germane to the current discussion 17:29:31 If they've already chosen to use sysvinit-core, we should just give them systemd-shim and move on with our lives. 17:29:45 vorlon,Diziet: I think you two are perhaps suffering from crosstalk 17:29:53 vorlon: You said 17:28 I certainly disagree with that but I don't know what you were disagreeing with 17:29:57 Diziet: vorlon was disagreeing with the statement he was relaying. 17:30:00 His previous line. 17:30:00 yes 17:30:01 OIC 17:30:03 Right. 17:30:05 OK. 17:30:20 I don't think we need any more discussion here on 746578 (swap deps) 17:30:31 right 17:30:32 Can we get anywhere on 762194/765803 (automatic switch) ? 17:30:49 not until the GR closes 17:30:51 17:27 I continue to be fine with passing a simple [decison] saying that our decision in February was not intended to imply any position on whether init should be changed during upgrade. 17:30:51 does anyone disagree with having a simple tc statement on automatic switching? 17:31:07 I'm not sure I see how deciding that conflicts with the current GR 17:31:15 dondelelcaro: I find such statements relatively pointless, but wouldn't object strongly 17:31:15 I don't think making that statement conflicts. 17:31:19 bdale opposes it but it sounds like we have a majority for it, and it would certainly move the debate forward. 17:31:25 dondelelcaro: what is that statement meant to be? 17:31:43 as I said above, I actually still think that automatically switching is the right thing to do on upgrade 17:31:44 I think deciding anything stronger potentially conflicts with the ballot option allowing packages to depend on an init system. 17:31:47 Can we get as far as "We aren't convinced we want to swap on upgrades and we invite submissions of a concrete set of technical changes to ensure that existing machines keep their existing inits, while new Linux installations get systemd" ? 17:31:56 vorlon: what Diziet and rra described; interpreting our previous decision as to not do automatic switching 17:31:56 vorlon: if packages are allowed to depend on a specific init system, then you *will* be switching on upgrade to jessie if you have those packages installed 17:32:08 vorlon: It's just a clarification in case anyone thought the TC had already decided in favor of automatic init swaps. 17:32:16 I don't know that it's important. 17:32:23 But if it helps, I'm fine with saying it, since it's true. 17:32:25 dondelelcaro: the problem I have is that if we say that, in the current climate, it's actually an assertion against switching 17:32:30 I think it is important. Several people have interpreted the TC decision that way. 17:32:45 I can see the benefits in terms of simplicity of Debian's default stack of switching, but I'm very concerned about its effects on deployed systems for the sorts of reasons rra was relaying earlier 17:32:49 however, notifying the admin that this has been done, so they have the opportunity to select a non-default init before reboot, is important 17:33:08 Can we get as far as "We aren't convinced we want to swap on upgrades and we invite submissions of a concrete set of technical changes to ensure that existing machines keep their existing inits, while new Linux installations get systemd" ? 17:33:11 rra, Diziet: ah; I hadn't seen that anyone was relying on TC authority for the actions they were taking in this regard 17:33:12 And the grub2 patch that's on me to deal with would help, it's true 17:33:18 (I keep asking this because no-one is saying yes or no...) 17:33:21 Diziet: I completely understand how important you think this is. But to re-start the GR process, and then call for votes here in parallel just doesn't sit well 17:33:27 vorlon: To be clear, I hadn't either, but Diziet said he'd seen it. 17:33:36 and I wouldn't expect withdrawing any presumed TC authority to change what the maintainers are doing 17:33:44 so such a statement indeed seems a no-op to me 17:33:45 vorlon: Yeah, agreed there. 17:34:12 Diziet: I don't think that stating that we don't want to swap on upgrades is something we can agree on 17:34:13 vorlon: right .. I see it as either a no-op, or given the current climate, a softly negative assertion 17:34:25 Diziet: at least, not while the GR is happening which seems to directly address this part of the question 17:34:28 dondelelcaro: That's not the question. The question is whether it's something that would pass a TC vote. 17:34:32 I'm done with consensus decisionmaking. 17:34:38 W 17:34:40 I would certainly be interested in someone working out the exact dependency changes required and testing them. I think that would make the discussion more concrete. 17:34:54 And allieviate some of Tollef's concerns, presumably. 17:35:10 to be clear, I would vote yes on such a statement if it presented itself, but as I don't think it would affect the outcome, I'd rather we get to the root question instead 17:35:28 i.e., to have the actual discussion about the default changing on upgrade 17:35:31 I think I agree with vorlon on that 17:35:34 That's not to say I'm not open to convincing. But everything done by my opponents in this whole war has been done on a majoritarian basis and I see no reason to limit myself to consensual acts. 17:35:58 Could we please stop this "war" thing? 17:36:01 cjwatson, vorlon: OK, thanks. I'm going to action myself to write that up. 17:36:32 #action Diziet to write up (a) clarification of February thing as suggested by rra (b) "invite changes" (as separate options) 17:36:48 Diziet: we can always go to majoritarian, but if we can agree, so much the better. 17:37:10 Yeah, we do seem to be able to reach consensus agreement on things in this area still, such as the libpam-systemd dependencies. 17:37:17 dondelelcaro: I and my allies have been being shat on by the majoritarians since February. It's too late for that. 17:37:34 Of course I'm happy to work to get consensus where we can do so quickly. 17:38:00 But perhaps we could shelve this metaargument which is going rapidly downhill. 17:38:09 Diziet: please 17:38:45 do we have anything else to discuss on this issue currently? 17:39:06 I don't think so. 17:39:10 #topic #766708 Request to override gcc maintainer changes breaking multiarch packages 17:39:50 I find myself tending to agree with Helmut. It's difficult because we've had so little interaction with Matthias but (a) I think he has a responsibility to put his case (even though Helmut has been trying to do it for him) and 17:39:52 I think this one is still being developed, but I'm currently not sure what the maintainer overhead is of this particular patch, and why it needs to be removed this close to jessie release 17:39:57 I thought I'd made up my mind on this, and then there was a message to the bug recently that basically argued that this facility is not needed, and I haven't digested that. 17:40:10 (b) making a change like this at this stage of the release, without discussion, is not very constructive. 17:40:29 If we really don't need this facility, then simplicity is obviously better, but when the people who are actively working on cross-compilation say they need something and are willing to maintain it, I'm inclined to defer to them. 17:40:29 Matthias does need to put his case clearly. That said as I indicated in my most recent message I'm not sure it actually prevents Helmut doing what he needs (though I have not tested my theory). 17:40:34 Also, what Diziet just said. 17:41:02 But I don't think it's in a place where we can really put a motion yet. 17:41:05 rra: I think you're thinking of Dmitri's message, to which Helmut presented a cogent-seeming response. 17:41:05 It's a little late in the game to be turning stuff off at this point. 17:41:16 Diziet: Ah, okay. I hadn't digested that part of the thread at all. 17:41:25 cjwatson: I don't think we should encourage Helmut to play core wars. 17:41:53 I think we should draft a proposal to overrule and see if any further counterarguments come up. 17:41:57 ok 17:42:03 my question was whether we should expect there to be a fix which doesn't require reverting the change available in the short term 17:42:04 I think a limited proposal is pretty easy to draft here 17:42:04 Perhaps not, but it depends why that change was made exactly, and I want to hear more from Matthias there. 17:42:20 yeah; I'd like to hear more too 17:42:31 Matthias's one response seemed to basically say because he disagreed with that approach and didn't want to maintain two approaches. 17:42:35 It seems obvious to me that Matthias must have known that this change would be unpopular in certain quarters. 17:42:49 I think therefore that he ought to have explained himself in advance. 17:42:55 yes 17:42:58 It's not like this is a trivial thing that no-one was using. 17:43:12 given that folks actually doing the work on porting are complaining, something went wrong 17:43:20 Yeah. 17:43:21 I am not sanguine about a maintainer override here; I don't understand why this has come to the TC in that vein. Is this not a case where everyone would be better served by the TC acting in a mediation role? 17:43:35 vorlon: seems likely 17:43:41 vorlon: that would be ideal 17:43:43 That would certainly be better. 17:43:45 vorlon: I think Matthias should have discussed the matter with his users. 17:43:48 There seems to be a substantial amount of bad feeling either way; I've heard passionate complaints from both sides 17:43:52 clearly very upset 17:43:58 there is, however, the timing issue around jessie freeze at issue, though, right? 17:44:01 Indeed. 17:44:04 Yeah, we're on the clock here. 17:44:05 right; mediation woudl be best going forward 17:44:07 But I don't at this point understand the details well enough to mediate, and would need to read up quickly 17:44:12 If this had come up 2 months ago, mediation, sure. 17:44:15 Do the porters use the *source* package from jessie? 17:44:21 Which is part of the reason why I have less sympathy than I would otherwise; this isn't the sort of change that I would make near the release freeze. 17:44:31 ansgar: Oh, good question. 17:44:43 Diziet: so, if we ask Matthias to revert *for jessie*, and work on mediating a longer term solution, could we get him to agree to that? 17:44:45 ansgar: The theory being that if so then they could sed it? 17:44:54 Diziet: I don't disagree that Matthias should have done this; the question is whether a maintainer override is the right tool here or if it will just make it harder for folks to work together in the future 17:44:58 keithp: Even Helmut is only asking for an overrule for jessie. 17:45:10 That was clear from his initial mail and Matthias hasn't said "sure" 17:45:14 cjwatson: No, the question is how relevant to change the source package in jessie is. 17:45:23 Diziet: right, I'd rather we get Matthias to agree to that instead of forcing the issue 17:45:31 Ah. Well, I think they do use it, but as I say I'm fuzzy on the details. 17:45:35 Yeah, if the porters are always working from sid, I'm not sure whether it matters that much what jessie releases with. 17:45:40 keithp: He's _already_ acted unilaterally, and _already_ declined to agree to that. 17:45:50 Oh perhaps you meant to stress *jessie* rather than *source*? :-) 17:45:53 We can't force him to answer emails (obviously) and we mustn't wait. 17:45:58 can someone approach Matthias to try to get him to respond to this? 17:46:34 I am very uncomfortable with the idea that we would decline to overrule a maintainer who has made a high-handed decision with poor communication and is unresponsive, precisely _because_ the maintainer is unresponsive. 17:46:52 The maintainer being unresponsive ought to make us more willing to overrule. 17:47:12 I agree 17:47:45 how about I give a week for a specific response; if not, I draft the override 17:47:47 That said, if someone is willing to reach out, it certainly doesn't *hurt* to do so. 17:47:57 I think we should put forward a draft within the next few days, and perhaps give it another week to see if the imminent formal process produces a response. But I would expect to want to have dealt with this issue within a matter of 2-3 weeks which means starting a vote in 1-2. 17:48:04 right 17:48:06 rra: Certainly. 17:48:09 I like Don's proposal. 17:48:13 * vorlon nods 17:48:15 works for me 17:48:16 dondelelcaro: I would prefer sooner but that would be tolerable. 17:48:23 I can draft the override, and just shove it into git for the time being 17:48:33 then we can move on it rapidly if necessary 17:48:34 dondelelcaro: yes, please do 17:48:35 And formally propose it in a week or so ? 17:48:35 I agree as well 17:48:41 dondelelcaro: That sounds great. 17:48:43 Yep 17:48:49 making it clear we're going to vote on this if it isn't resolved "naturally" is a good strategy 17:49:10 and making it pretty darn clear what the vote is likely to be :-) 17:49:10 #action dondelelcaro to draft override for #766708 in git; move forward formally in a week 17:49:25 #topic #750135 Maintainer of aptitude package 17:49:31 I think aba was going to head this issue up 17:50:05 #action aba to propose a process to try out on #750135 Including the maintainer perhaps providing private response to us, and also perhaps an irc conversation 17:50:08 that's what I have for it 17:50:16 I don't know if anything has happened there 17:50:20 NAFAIAA 17:50:24 Yeah, at hte moment I have no data. 17:50:29 ditto 17:50:32 ok 17:50:44 I'll try to ping aba about that later 17:50:44 Would someone else like to take this action item ? 17:51:26 ... tumbleweed ... 17:51:28 heh 17:51:31 #action dondelelcaro to ping aba about process for #750135 17:51:38 I'll just ping aba about it, and see what happens 17:51:43 I guess that will do. 17:51:54 #topic Additional Business 17:52:01 We skipped the constitutional stuff. 17:52:05 oh, right 17:52:08 let me go back to that 17:52:19 #topic #636783 constitution: super-majority bug 17:52:22 I think I have to go in 5 17:52:24 * rra has about three minutes and then has to go to a work meeting. 17:52:26 ok 17:52:28 I have put that on hold. If someone else wants to pick it up that's fine of course. I don't propose to do anything about it until after the init system GR vote is concluded. 17:52:38 That sounds right to me. 17:52:38 good 17:52:44 OK 17:52:46 OK 17:52:47 one GR at a time is enough 17:52:53 #topic #636783 constitution: casting vote 17:52:54 One GR at a time is generally enough-- yeah. :) 17:53:08 should I go through these individually? Or? 17:53:08 That goes for all of these. 17:53:19 #topic #636783 constitution: TC member retirement/rollover 17:53:23 AJ is pursuing the term limit thing. 17:53:24 Oh, so we skipped the constitutional stuff, but it's fine for us to have done so. 17:53:27 I think this is the only one which has some stuff 17:53:29 rra: Yes. 17:53:33 Diziet: did you get to a concrete draft on these yet? I've read things but forget the current status. 17:53:38 That's fine. But I haven't read his proposal in detail. 17:53:40 I'm inclined to let AJ run with it if he wants to. 17:53:47 bdale: Most of them I think. 17:53:50 ok 17:54:00 rra: I certainly don't feel I have standing to stop him but I wish he'd wait a bit. 17:54:10 Diziet: Well, I don't think he's ready to propose something. 17:54:23 I'd like to have a conversation about it when debian-vote is a bit less of a madhouse. 17:54:27 Yes. 17:54:31 Right now, the conversation would be lost. 17:54:58 right 17:55:06 anything else with this? 17:55:10 But my impression is that we've mostly hammered out the broad strokes and it's mostly about the details. 17:55:17 Yes. 17:55:23 #agreed Postpone constitutional questions until -vote less mad. 17:55:27 So I suspect we could resolve it relatively quickly when there's some quiet. 17:55:40 #topic Additional Business 17:55:48 rra: I think so 17:56:21 AOB> None from me. 17:56:31 I have nothing further, and actually need to run. 17:56:47 I have to go, too. 17:56:49 Goodnight all. 17:56:53 nite 17:56:55 #endmeeting