Add results from latest TC Chair election
[debian-ctte.git] / meetings / 20141204 / debian-ctte.2014-12-04-18.00.log.txt
1 18:00:01 <dondelelcaro> #startmeeting
2 18:00:01 <MeetBot> Meeting started Thu Dec  4 18:00:01 2014 UTC.  The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
3 18:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4 18:00:07 <dondelelcaro> #topic Who is here?
5 18:00:10 <dondelelcaro> Don Armstrong
6 18:01:16 <bdale> Bdale Garbee
7 18:01:36 <keithp> Keith Packard
8 18:01:59 <dondelelcaro> we have regrets from aba and cjwatson
9 18:02:02 <vorlon> Steve Langasek
10 18:02:10 <dondelelcaro> I think that's everyone accounted for?
11 18:02:17 <dondelelcaro> #topic Next Meeting?
12 18:03:02 <dondelelcaro> currently the next meeting is the 18th instead of christmas day; does that still work for everyone?
13 18:03:16 <bdale> fine with me
14 18:03:21 <keithp> wfm
15 18:03:56 <dondelelcaro> #action dondelelcaro to ask aba and cjwatson if the 18th of December works for them still
16 18:04:22 <dondelelcaro> #topic #769972 New member selection process
17 18:04:38 <vorlon> yeah, fine with me
18 18:04:41 <dondelelcaro> cool
19 18:04:49 <dondelelcaro> we've gotten a number of responses here, and a number of acks. I'm still waiting on a few more people to respond
20 18:05:06 <bdale> yep, thanks for taking the lead on poking for acks
21 18:05:09 <dondelelcaro> no problem
22 18:05:20 <bdale> so our habit has been to deliberate on the list in private
23 18:05:26 <bdale> I assume we want to continue that?
24 18:05:37 <dondelelcaro> I think so
25 18:05:44 <bdale> if so, we should confirm that we know the list of subscribers on the private list has been updated
26 18:05:54 <dondelelcaro> OK
27 18:06:13 <dondelelcaro> I think I know where that is, so I can verify it
28 18:06:24 <bdale> once that's done, an email to that list with the list of candidates nominated, and who has accepted or declined the nomination, should go to the private list
29 18:06:31 <dondelelcaro> #action dondelelcaro to verify the debian-ctte-private list subscribers is accurate
30 18:06:39 <dondelelcaro> right
31 18:07:01 <bdale> I know your text to the nominees said those who accept might be publicly acknowledged, but that has not been our habit in the past
32 18:07:17 <dondelelcaro> bdale: well, it has to be
33 18:07:23 <dondelelcaro> bdale: either during discussion, or when we vote
34 18:07:34 <bdale> not at all clear
35 18:07:43 <dondelelcaro> unless we're just going to vote Y/N on someone?
36 18:08:18 <bdale> last time, we discussed the nominees privately and reached consensus on who to put forward to the DPL
37 18:08:34 <keithp> so the public vote is a mere formality?
38 18:08:42 <bdale> it has been in the past
39 18:09:00 <dondelelcaro> hrm...
40 18:09:12 <bdale> if we can't reach consensus and actually need condorcet-style voting to decide who to put forward, that would be a new experience
41 18:09:16 <dondelelcaro> §6.2 says "However, votes on appointments must be public."
42 18:09:30 <bdale> right, which is why we always hold a public vote
43 18:09:32 <dondelelcaro> s/6.2/6.3.4/
44 18:09:57 <bdale> said vote has always followed a process of reaching private consensus, as a way of "not embarrassing" candidates who were not chosen
45 18:10:00 <vorlon> but AFAICS that only requires a public up/down vote on a given appointment
46 18:10:11 <dondelelcaro> we must have had this discussion last time, and I'm just misrembering our consensus
47 18:10:14 <dondelelcaro> OK
48 18:10:26 <bdale> I'm not trying to say that we *have* to do it this way, but as the person who now has the longest length of service, I'm just trying to explain how it's been done in the past
49 18:10:27 <dondelelcaro> yeah, that all seems reasonable
50 18:10:37 <Mithrandir> (you did have approximately this discussion last time too, yes)
51 18:10:46 <bdale> we always do .. ;-)
52 18:10:57 <Mithrandir> except that last time, you didn't agree on keithp vs pkern and so that bit was public, IIRC.
53 18:11:23 <dondelelcaro> and I probably made the same arguments too. ;-)
54 18:11:48 <bdale> so, to be clear, I'm all for openness and not trying to drive a particular process here
55 18:12:10 <bdale> I *do* want us to drive to at least 2 nominations for DPL approval with due haste, however
56 18:12:17 <dondelelcaro> right
57 18:12:41 <dondelelcaro> OK. should we close nominations?
58 18:12:59 <keithp> bdale: 6.3.4 seems to encourage private discussions as a process at least
59 18:13:00 <bdale> on the assumption that one of the options imposing term limits passes GR, having enough time for new people to come up to speed before I (and possibly vorlon) get the boot late in 2015 seems prudent
60 18:13:12 <ansgar> How does the voting work if you need >1 candidate?
61 18:13:27 <bdale> nothing says we can't do a consensus ranking in private
62 18:13:57 <bdale> if we were to do so and the top N were obvious, running a public y/n vote on the top N as those to propose to the DPL could happen and be completely "legal"
63 18:13:58 <keithp> ansgar: I think the public appearance is that individual ballots for each proposed member be voted on
64 18:14:13 <dondelelcaro> right
65 18:14:41 <dondelelcaro> yeah, either one would be OK
66 18:14:57 <keithp> the goal is to build a ctte with broad experience and knowledge, sometimes that means picking a suitable set of candidates ensuite
67 18:15:05 <dondelelcaro> does anyone object to keeping the nominations list private?
68 18:15:25 <bdale> the whole public/private thing has always been a subject it's worth our discussing explicitly.  trust works both ways here.  we want to be able to openly and honestly discuss candidate qualifications within the ctte, I at least feel we owe it to the ones not selected to not air all their dirty laundry in public
69 18:15:43 <dondelelcaro> right
70 18:16:00 <keithp> bdale: perhaps summarize the positive qualifications of each proposed candidate as a part of our submission to the DPL?
71 18:16:13 <bdale> not a bad thought
72 18:16:38 <keithp> Give the DPL an understanding of our reasoning at least
73 18:16:55 <keithp> (and the rest of the project in parallel)
74 18:16:59 <bdale> vorlon: any thoughts regarding this?
75 18:17:14 <vorlon> sorry, brain contention with work stuff
76 18:17:19 <bdale> np
77 18:17:36 <bdale> <dondelelcaro> does anyone object to keeping the nominations list private?
78 18:17:36 <vorlon> this is the public/private question?
79 18:17:45 <bdale> correct
80 18:17:45 <vorlon> I greatly prefer them to be kept private
81 18:17:49 <bdale> ok
82 18:17:54 <bdale> then Don, the answer is known
83 18:18:06 <dondelelcaro> #agreed keep nomination list private
84 18:18:12 <keithp> vorlon: I suggested that perhaps we summarize our reasoning for the proposed candidates in our note to the DPL
85 18:18:13 <vorlon> in theory people can be comfortable putting themselves forward without having the TC publically rejecting them
86 18:18:18 <dondelelcaro> right
87 18:18:24 <bdale> agreed
88 18:18:34 <bdale> and I like Keith's suggesting
89 18:18:36 <vorlon> I don't think we are under any obligation to even share the full list of candidates with the DPL
90 18:18:42 <bdale> we are not
91 18:19:07 <dondelelcaro> does anyone have an objection to me thanking everyone (in general) who was nominated and agreed to be considered, and then drawing the nominations to a close in say, 48 hours?
92 18:19:11 <bdale> the whole idea of publicly asking for nominations is relatively new
93 18:19:15 <vorlon> or maybe "proposed candidates" means just the ones we are recommending to the DPL?
94 18:19:19 <keithp> I volunteer to write up the summaries, iterating in private
95 18:19:25 <bdale> dondelelcaro: good plan
96 18:19:28 <vorlon> dondelelcaro: sounds good to me
97 18:19:36 <dondelelcaro> OK.
98 18:19:39 <keithp> dondelelcaro: agreed
99 18:19:44 <bdale> feel free to mention that deliberations will be conducted in private
100 18:20:10 <dondelelcaro> #action dondelelcaro to thank everyone (in general) who was nominated and agreed to be considered, and drawing nominations to a close in 48 hours, indicate that delibrations will happen in private
101 18:20:41 <dondelelcaro> I've got the list of nominees and all of the mails, so I'll send that to ctte-private to summarize everything
102 18:20:46 <bdale> thank you
103 18:21:08 <dondelelcaro> #topic #636783 constitution: super-majority bug
104 18:21:29 <dondelelcaro> I've got all of these still on the agenda; does anyone object to just skipping them until after the TC retirement vote?
105 18:21:42 <bdale> I would be pleased with that
106 18:22:08 <bdale> I do think we have enough stuff to call for a GR at some point, but I'd like to table this until after the current GR closes
107 18:22:15 <dondelelcaro> sounds good
108 18:22:26 <keithp> one GR at a time seems like a pretty good plan
109 18:22:27 <dondelelcaro> I'd also be OK with tabling it until after jessie releases
110 18:22:34 <bdale> I'm fine with that too
111 18:22:40 <bdale> we have more urgent items on our agenda, frankly
112 18:22:50 <dondelelcaro> #agreed table #636783 until at least the GR is done, possibly jessie release
113 18:22:58 <dondelelcaro> #topic #741573 menu systems and mime-support
114 18:23:35 <dondelelcaro> keithp: I think this needed one more position for this, IIRC?
115 18:23:43 * dondelelcaro can't remember if that got done or not
116 18:23:44 <keithp> I've had a bunch of emails on this topic, one in particular caught my attention asked that we focus on resolving the issue brought to us and not attempt to rewrite policy ourselves?
117 18:24:53 <dondelelcaro> OK
118 18:24:56 <bdale> Russ had thoughts on that .. sorry he chose to resign before this concluded
119 18:25:04 <keithp> any thoughts on that from the remaining members?
120 18:25:46 * bdale waits for the BTS to paint in his browser...
121 18:25:56 <keithp> I can't even reach the BTS today...
122 18:26:50 <dondelelcaro> hrm; that's no good
123 18:27:24 <bdale> so the original question was Plessy asking us to over-rule Bill's veto on the proposed policy change?
124 18:27:35 <dondelelcaro> right
125 18:27:37 <keithp> yes
126 18:28:50 <ansgar> Well, Plessy asked for arbitration without specifying what that means in detail.
127 18:28:53 <keithp> I think we can hold an up/down vote on that direct question pretty easily
128 18:29:01 <vorlon> keithp: policy on this needs fixed, the standard policy process has failed, and someone needs to step up to get it sorted out; the suggestions that the TC should limit itself to the original question are way off base
129 18:29:19 <ansgar> Ah, no it specifically asks for an override later.
130 18:29:45 <hartmans> vorlon: It would be really cool if the TC documented that the policy process had failed and explained how.
131 18:29:56 <keithp> vorlon: perhaps the TC should solicit policy editing proposals and then pick amongst them, rather than writing the changes ourselves then?
132 18:30:01 <vorlon> whether we choose to make a recommendation vs. exercising one of the TC's firmer powers would be open to discussion
133 18:30:07 <hartmans> I think that would make me and possibly Charles feel a lot more comfortable with a decision to write policy.
134 18:30:19 <bdale> hartmans: good point.  it appears consensus was reached, then ignored.
135 18:30:20 <vorlon> keithp: I solicit a policy proposal from you
136 18:31:04 <keithp> I wish I could see the full bug history now...
137 18:31:26 <bdale> it painted for me, was just slow
138 18:31:58 <vorlon> bdale: if there was someone disagreeing with the "consensus" and refusing to apply it, then it wasn't consensus
139 18:32:23 <keithp> vorlon: 'rough consensus' doesn't mean unanimity
140 18:32:56 <bdale> old argument .. "group as a whole" vs "everyone agreed"
141 18:33:10 <dondelelcaro> our choices here are really 1) override 2) write policy ourselves 3) tell -policy to try again with CTTE guidance on policy, I guess?
142 18:33:32 <bdale> I think so
143 18:33:54 <keithp> dondelelcaro: or abstain from deciding, which is our current situation due to inaction
144 18:33:57 <dondelelcaro> did we ever figure out what Bill's specific objections were to the policy?
145 18:34:06 <bdale> I don't think so
146 18:34:28 <dondelelcaro> would an ultimatum be useful here?
147 18:34:35 <vorlon> keithp: our policy process isn't based on "rough consensus", but on a stricter definition of consensus
148 18:34:53 <keithp> dondelelcaro: asking Bill to explain his issues or face an override?
149 18:35:02 <dondelelcaro> keithp: right
150 18:35:15 <bdale> Bill was CC'ed in but never joined the thread
151 18:36:14 <dondelelcaro> yeah; that seems to be a common problem in these cases
152 18:36:18 <keithp> dondelelcaro: something like 'we're inclined to agree with the plaintiff and override your veto and are interested in hearing cogent arguments supporting your position?'
153 18:36:25 <dondelelcaro> keithp: right
154 18:36:53 <dondelelcaro> does anyone object to that with a time limit? say 1 month?
155 18:36:58 <dondelelcaro> or two weeks?
156 18:37:00 <bdale> keithp: since you've taken the drafting lead, do you want to send that email?
157 18:37:04 <keithp> bdale: will do
158 18:37:11 <keithp> once I can reach the bug again :-)
159 18:37:40 <bdale> we've let this go long enough that any decision will have no impact on jessie, so let's get on with it, but don't go nuts
160 18:37:52 <keithp> also letting the policy team understand that I'm interested in *not* having the TC responsible for editing policy, but just enabling them to make progress with their normal process
161 18:37:58 <vorlon> keithp: by "override the veto", however, you don't mean applying the original proposed policy change, do you?
162 18:38:18 <keithp> vorlon: I can't see what that is at present...
163 18:38:36 <vorlon> it's the much earlier proposal that should be superseded by the much better one that you drafted ;)
164 18:38:42 <keithp> at this point, I can't actually recall the precise wording
165 18:40:38 <dondelelcaro> should we just try the debian-policy consensus method for keithp's draft in the meantime?
166 18:41:27 <keithp> dondelelcaro: I could bring my proposal to the policy team and see what they think, using their normal process
167 18:41:30 <bdale> meaning you want to learn whether the current composition of the TC has consensus around keithp's current draft?
168 18:42:13 <dondelelcaro> bdale: no, I meant bringing keithp's proposal to the policy team
169 18:42:16 <bdale> ok
170 18:42:25 <bdale> yes, that'd be a great step
171 18:42:36 <bdale> if it achieves consensus there, we'd be done
172 18:43:08 <dondelelcaro> vorlon: does that work for you?
173 18:43:59 <dondelelcaro> I'll just assume that it does
174 18:44:09 <vorlon> sure
175 18:44:09 <dondelelcaro> and if not, it can be re-raised
176 18:44:12 <dondelelcaro> cool
177 18:44:34 <keithp> vorlon: shall I stick your seal-of-approval on my proposal?
178 18:44:35 <dondelelcaro> #action keithp to bring his draft of #741573 to -policy for consensus building
179 18:44:38 <dondelelcaro> heh
180 18:44:43 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
181 18:44:52 <dondelelcaro> oh, actually, let me throw a quickie in here
182 18:45:07 <dondelelcaro> #topic #770789 df sizes output format
183 18:45:22 <dondelelcaro> this is YE OLDE SI units vs 2^10 units
184 18:45:40 <keithp> we're still having that discussion?
185 18:45:41 <dondelelcaro> and frankly, I'm just going to punt this back to the maintainer to close
186 18:45:50 <dondelelcaro> keithp: the bug submitter is notorious
187 18:46:19 <dondelelcaro> does anyone object to a quick "we decline to override the maintainer" draft for this issue? [should we even bother?]
188 18:46:56 <keithp> Sounds good to me
189 18:47:07 <ansgar> +1
190 18:47:36 <ansgar> Also the documentation says "print sizes in powers of 1024" for -h vs. "
191 18:47:42 <dondelelcaro> #action dondelelcaro to draft "we decline to override the maintainer" for #770789
192 18:47:46 <ansgar> print sizes in powers of 1000" for -H. Seems pretty clear.
193 18:47:51 <dondelelcaro> ansgar: yeah, I'm pretty sure the documentation is correct
194 18:47:53 <vorlon> keithp: if it's the same proposal, yes
195 18:48:18 <bdale> dondelelcaro: thumbs up from me
196 18:48:24 <keithp> vorlon: I'll probably take an editing pass to make sure it says what I mean, and run that past you if you're willing
197 18:48:25 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
198 18:48:56 <ansgar> For the init upgrade I think there were three proposals.
199 18:48:59 <dondelelcaro> (on the previous bug, I'm wondering if we shouldn't require a DD to raise the issue to the CTTE; we can obviously approve it ourselves)
200 18:49:10 <vorlon> keithp: +1
201 18:50:04 <dondelelcaro> so for this bug, I'm happier that we actually have concrete proposals, though I don't think any of them have had enough testing
202 18:50:29 <ansgar> I think two had issues with installing sysvinit in some cases.
203 18:50:39 <ansgar> And the last one just arrived ~2 hours ago.
204 18:50:48 <Mithrandir> ansgar: the xen console one?
205 18:51:47 <vorlon> dondelelcaro: there's a fundamental question here that we've kind of leap-frogged over
206 18:51:57 <ansgar> First proposal in 762194#124, I tested it in #142
207 18:52:12 <dondelelcaro> vorlon: whether we should actually switch the defaults?
208 18:52:14 <vorlon> which is whether we agree that users *should* be kept on sysvinit on upgrade, if we find a workable solution
209 18:52:17 <vorlon> yes
210 18:52:54 <hartmans> If you haven't read <5e27043707590dc20fb0b0b083912d92@iwakd.de then I recommend it.
211 18:52:56 <keithp> vorlon: I don't think we leap-frogged; we asked first whether that was even possible
212 18:53:21 <dondelelcaro> vorlon: right; I think that's the "decline to overide init maintainers" option, which I believe should be an option in this vote
213 18:53:23 <hartmans> It seems to have a good sumarry of the proes/cons of switching; seems to have good analysis of the proposals; and also very interesting discussion of jessie+2
214 18:53:28 <ansgar> Then there's #157 (totally untested AFAIK).
215 18:53:48 * dondelelcaro really should make msg-id searching work for the BTS
216 18:53:59 <vorlon> keithp: however, if the consensus within the TC is that an upgrade *should* automatically switch, then we should stop wasting folks' time trying to come up with proposals on how to avoid it
217 18:54:03 <hartmans> That's the one from Christian Seiler
218 18:54:33 <vorlon> (this was why I dissented on Diziet's last resolution on this subject)
219 18:54:52 <dondelelcaro> vorlon: true... I must admit that I think we should switch by default
220 18:55:42 <dondelelcaro> vorlon: I was hoping that someone would come up with some good way to switch by default, but provide an easier method for people to opt out in detectable configurations (or providing a "boot with sysvinit" option in grub, or something like that)
221 18:56:09 <ansgar> dondelelcaro: There's a patch for boot-with-sysvinit option in grub written by the systemd people.
222 18:56:11 <Mithrandir> dondelelcaro: cjwatson has said he'll provide a "boot with sysvinit" option in grub, afaik.
223 18:56:11 <dondelelcaro> does anyone on the CTTE currently think that we shouldn't be switching on default?
224 18:56:33 <dondelelcaro> ansgar, Mithrandir: right, that's actually why I was thinking of it. ;-)
225 18:56:49 <ansgar> #757298
226 18:56:49 <keithp> dondelelcaro: would the resulting system be bootable with sysvinit by setting the appropriate kernel command line option?
227 18:57:00 <vorlon> right; we can't actually detect problems during the upgrade and make a change to which packages we'll install as part of that upgrade, because that would be incestuous within the package manager
228 18:57:01 <dondelelcaro> keithp: I believe so
229 18:57:07 <ansgar> keithp: Yes, init=/lib/sysvinit/init
230 18:57:12 <keithp> dondelelcaro: Mithrandir says it would be as well
231 18:57:14 <vorlon> but maybe we can detect and flag it to grub
232 18:57:34 <Mithrandir> keithp: sysvinit in jessie ships init as /lib/sysvinit/init, iirc.
233 18:57:40 <vorlon> or at least flag it to the admin, and give 'install sysvinit-core' as one of the suggestions
234 18:57:44 <Mithrandir> so you just need to point the kernel's init argument in that direction.
235 18:57:57 <vorlon> AIUI, Md was already planning on doing inittab detection on upgrade
236 18:58:04 <keithp> Mithrandir: and make sure that sysvinit is installed
237 18:58:05 <Mithrandir> both systemd's and upstart's command line tools know how to speak the telinit protocol
238 18:58:12 <Mithrandir> keithp: it's essential in wheezy
239 18:58:13 <vorlon> and cjwatson was planning on providing cleaner grub selection
240 18:58:19 <dondelelcaro> would an option that says "we decline to override init system maintainers; noting good discussion with #757298 and similar methods to enable sysvinit in specific custom setups"
241 18:58:29 <dondelelcaro> be acceptable in principle?
242 18:58:57 <Mithrandir> so if you do a plain upgrade and then don't remove packages, it'll be there.  If you upgrade, then remove sysvinit (either directly or because it's unused), there's little that can be done.
243 18:59:19 <Mithrandir> unused → marked as unused in apt, so removed with apt-get autoremove.
244 18:59:34 <keithp> Mithrandir: as long as the autoremove is done after the system is running, that seems fine
245 18:59:48 <keithp> I think the concern is that the upgrade result in a system that doesn't boot
246 19:00:16 <bdale> right
247 19:00:26 <ansgar> sysvinit should not be marked as automatically installed.
248 19:00:31 <Mithrandir> keithp: autoremove has to be called by the admin, it's not called automatically.
249 19:00:43 <dondelelcaro> ansgar: yeah, I would think it wouldn't be by default either. You'd have to do it manually
250 19:00:45 <ansgar> Everything debootstrap installs counts as "manually installed" as far as I know.
251 19:00:55 <dondelelcaro> though I haven't tested that
252 19:01:09 <keithp> Mithrandir: sounds good
253 19:01:09 <ansgar> Also also did to keep sysvinit everywhere so far.
254 19:01:15 <ansgar> s/Also/I/
255 19:01:52 <dondelelcaro> ansgar: sounds good. I suppose if not, someone could provide a Suggests: sysvinit in the init package for a release
256 19:01:52 <Mithrandir> keithp: at some point, it's the user shooting their foot off.  We can make it harder for them, but we can't prevent it completely.
257 19:02:19 <keithp> Mithrandir: memories of the grub->grub2 transition are painful for some :-)
258 19:02:45 <Mithrandir> in addition to the earlier mentioned changed inittab detection, the plan is, afaik, to detect known-problematic fstabs too.
259 19:03:04 <Mithrandir> keithp: sure, I'm not trying to downplay the possible pain.
260 19:03:29 <helmut> doesn't the alternate dependency of "init" on sysvinit-core already prevent autoremoval?
261 19:03:46 <dondelelcaro> helmut: dunno
262 19:03:59 <ansgar> helmut: No. sysvinit-core is not installed.
263 19:04:02 <Mithrandir> helmut: that won't prevent autoremoval of sysvinit.
264 19:04:31 <dondelelcaro> anyway, I think these issues can be discussed elsewhere; does anyone object to such an option?
265 19:04:40 <dondelelcaro> 10:58:26 <dondelelcaro> would an option that says "we decline to override init system maintainers;  noting good discussion with #757298 and similar methods to enable sysvinit in  specific custom setups"
266 19:04:54 <dondelelcaro> do we need to keep spending people's time on non-upgrade options?
267 19:05:05 <dondelelcaro> s/upgrade/switch-on-&/
268 19:05:09 <vorlon> I would go further
269 19:05:33 <bdale> vorlon: ?
270 19:05:42 <keithp> dondelelcaro: options that let people declare as a part of the upgrade process to not switch still seem useful, but it looks like we have good options already
271 19:05:45 <vorlon> if we actually agree with this in principle, I'd like an affirmative resolution saying that we recommend/support systemd being the default init system for upgrades as well as new installs
272 19:07:20 <keithp> vorlon: just as a '6.1.5 Offer advice' motion, that seems good to me
273 19:07:28 <dondelelcaro> I'm personally OK with that as well
274 19:07:35 <dondelelcaro> vorlon: do you want to draft that? or should I?
275 19:08:06 <dondelelcaro> (we're also running a bit over time here)
276 19:08:42 <vorlon> dondelelcaro: depends on how soon we expect it done
277 19:08:59 <dondelelcaro> well, I can start drafting it, and you can modify it
278 19:09:00 <dondelelcaro> heh
279 19:09:08 <dondelelcaro> probably would be good to get to it sooner rather than later
280 19:09:34 <dondelelcaro> #action dondelelcaro to draft affirmative resolution on #762194 noting #757298 et al
281 19:09:41 <dondelelcaro> #topic #766708 Request to override gcc maintainer changes breaking multiarch packages
282 19:10:32 <vorlon> dondelelcaro: that sounds like a plan :)
283 19:11:06 <dondelelcaro> on #766708, I think we might be too late for jessie
284 19:12:20 <dondelelcaro> I'm sort of unhappy about this bug, for too reasons: 1) it was brought to the CTTE really quickly without any attempt at concensus 2) The changes were made so close to the release of jessie that anyone who disagreed basically had no option
285 19:12:35 <dondelelcaro> I don't know how to express that in a constructive way, though
286 19:12:36 <keithp> seems like this bug only targets jessie to me; after that, it seems like there's reasonable consensus that using better supported mechanisms is the right way?
287 19:13:37 <helmut> keithp: no. #771070
288 19:14:26 <dondelelcaro> keithp: I think there's agreement that there might be a better method, but disagreement as to whether the other method even works or can work
289 19:14:43 <keithp> yeah
290 19:15:04 * dondelelcaro honestly hasn't done enough work in this particular multi-arch space to speak with even modest authority on it, though
291 19:15:21 <bdale> I haven't either .. I did see 771070, though
292 19:15:36 <keithp> and I even maintain a GCC package in the archive...
293 19:15:41 <dondelelcaro> heh
294 19:15:52 <keithp> (non self-hosting though)
295 19:16:50 <keithp> I am starting to get a sense of the politics here though, and of course both sides have valid points...
296 19:16:59 <bdale> my sentiment too
297 19:17:04 <dondelelcaro> yeah
298 19:17:30 <dondelelcaro> maybe the right solution is for someone to pay for a sprint, and force all of the major parties to sit in a room together and figure this out
299 19:17:41 <vorlon> well
300 19:17:44 <helmut> (that did happen in august)
301 19:17:46 <vorlon> the parties were all at a sprint
302 19:17:47 <vorlon> yeah
303 19:17:52 <dondelelcaro> oh. right.
304 19:18:03 <vorlon> clearly they did not all come away with the same understanding after that one
305 19:18:10 <Mithrandir> shouldn't have let them fly home until they were in agreement, then. :-P
306 19:18:12 <dondelelcaro> we never get easy solutions here! ;-)
307 19:18:14 <keithp> helmut: can you summarize for me what about the old solution doesn't meet 771070's desires?
308 19:18:28 <vorlon> AIUI everyone believed there was an agreement ;)
309 19:18:49 <helmut> keithp: which one is "old"?
310 19:18:49 <keithp> vorlon: shipping code should have been a requirement then
311 19:19:09 <keithp> helmut: the one used by the existing packages that actually results in working compilers
312 19:19:51 <vorlon> keithp: sorry, a requirement for what?
313 19:20:02 <keithp> vorlon: for letting them go home
314 19:20:08 <vorlon> well
315 19:20:24 <vorlon> the shipping of the code is, AIUI, the problem
316 19:20:27 <helmut> keithp: primary arguments being made: 1) cross architecture build-depends not supported by infrastructure 2) multiarch version lock frequently results in bd-uninstallable 3) the actual packages are not able to cross build gcc (lacking languages)
317 19:20:52 <keithp> helmut: thanks
318 19:20:58 <helmut> keithp: non-exhaustive
319 19:21:01 <keithp> sure
320 19:22:13 <helmut> could someone voice wookey? (he fails to register with nickserv atm)
321 19:22:49 <wookey> thank you
322 19:23:08 <wookey> the argreement was that whatever was working first would get uploaded
323 19:23:40 <wookey> keithp: the main disgreemnet is actually about multilib support AIUI
324 19:24:05 <wookey> the existing (in unstable) toolchains are one-arch each
325 19:24:20 <vorlon> wookey: doko has pointed out to me privately that this was never an agreement
326 19:24:27 <dondelelcaro> (is everyone still good on time?)
327 19:24:30 <helmut> reference: 20140829095214.GV19999@stoneboat.aleph1.co.uk section 3.13
328 19:25:10 <bdale> I just negotiated peace with my wife .. so I'm ok for a while longer
329 19:25:36 <wookey> vorlon: well I honestly don't understand that.
330 19:26:20 <vorlon> then I guess that's the crux of the misunderstanding
331 19:26:21 <wookey> but it's true that I don;t think he helped write the report afterwards. The rest of us ended up doing it (all on the wiki)
332 19:26:54 <wookey> but this is very old arguement anyway. The bootstrap meet was just re-iteration 8 or so
333 19:27:24 <wookey> WR jessie I think the question is, will 4.9.2-X migrate?
334 19:27:39 <wookey> if not then there is nothing to decide on this usefully
335 19:28:07 <wookey> and we can punt to the more substantive 770070 (?)
336 19:28:31 <dondelelcaro> does 4.9.1 still carry the multi-arch cross patches?
337 19:28:51 <wookey> the patch to the 4.9.1-19 in jessie is the 5-liner that started this bug
338 19:28:53 <helmut> dondelelcaro: the jessie version carries most (minus two hunks) the sid version doesn't
339 19:29:01 <wookey> the patch the what is now in unstable is 5K
340 19:29:06 <dondelelcaro> OK
341 19:29:12 <wookey> there is a big difference in maintenance burden
342 19:29:30 <wookey> (if we decide to maintain it outside gcc)
343 19:30:26 <wookey> although of course versoins don;t change often in jessie, so it's do-able, just very annoying
344 19:30:34 <helmut> in my other mail I asked, about options for action on the gcc/jessie issue. are there any options left?
345 19:30:46 <keithp> wookey: it does seem like a practical solution for jessie then
346 19:31:27 <dondelelcaro> so I guess we can punt for jessie, but we need to address this issue more substantiatively going forward
347 19:31:29 <wookey> _if_ a new gcc is not going to migrate, but I suspect there are serious bugs which mean that will happen?
348 19:31:33 <helmut> i.e. are we discussing the 766708 or 771070 atm?
349 19:31:39 <dondelelcaro> helmut: both
350 19:31:40 <wookey> I don;t know...
351 19:31:54 <wookey> mostly 766708, I thought
352 19:32:05 <dondelelcaro> yeah, mainly #766708, but they're sort of inter-related
353 19:32:07 <keithp> helmut: I'm trying to focus on 766708 as that seems more pressing for jessie
354 19:32:19 <keithp> (if not, in fact, already too late)
355 19:32:30 <vorlon> my understanding is that the trigger for the changes in gcc-4.9 was the upload of the cross-toolchain packages to the archive, which imposes a maintenance burden on the gcc maintainers, and was not agreed with them
356 19:32:56 <vorlon> and that, from doko's POV, these uploads happened over his explicit objection
357 19:33:13 <vorlon> (but there's no need to try to adjudicate what was or wasn't said/agreed at the sprint)
358 19:33:40 <vorlon> so if there was agreement to not include these toolchain packages in the archive, and they were withdrawn, doko might be willing to reenable this code path for jessie?
359 19:33:55 <vorlon> if that happened, would that be an improvement from your (helmut/wookey) pov?
360 19:35:12 <wookey> hmm, not sure. $people still want toolchains in unstable too, so the argument remains the same
361 19:35:22 <wookey> but I guess it might
362 19:35:36 <dondelelcaro> wookey: I suppose we'd address the issues for unstable when we tackle #771070
363 19:35:43 <wookey> this code was happily in gcc for 2 years....
364 19:35:53 <vorlon> we can deal separately with the question of whether gcc-4.9 will migrate or not.  If there's agreement on the technical solution, we could talk with the release team about using testing-proposed-updates
365 19:36:21 <wookey> dondelelcaro: right
366 19:36:42 <dondelelcaro> ok
367 19:37:24 <wookey> so we'd move the unstable toolchains to experimental?
368 19:37:27 <dondelelcaro> so lets try to get agreement around this for jessie via tpu, and then tackle the complete question in a more thourough discussion
369 19:37:53 <dondelelcaro> (sorry that we're being so late here)
370 19:38:18 <wookey> I have started a long answer to 771070, but not finished yet.
371 19:38:31 <keithp> from my perspective, I wonder if wookey thinks that reasonable cross compilers can be built with doko's preferred approach
372 19:38:34 <vorlon> if we were able to ensure they stayed in experimental, it seems to me that would relieve the support burden on the gcc maintainers
373 19:38:45 <helmut> vorlon: my reason for forwarding this to the ctte was that suddenly there was *no* way to build cross compilers. I don't care much as long as it works, I summarized the bugs with the supported method on the ctte bug
374 19:38:49 <vorlon> since responsibility for keeping those packages buildable/installable would lie solely with the cross-toolchain maintainer
375 19:39:05 <dondelelcaro> #agree get agreement to #766708 around pulling the cross-packages (to experimental?), reinstate patches, etc.
376 19:39:17 <dondelelcaro> ok. I'm going to move on, because I'm running out of time myself
377 19:39:21 <dondelelcaro> #topic #750135 Maintainer of aptitude package
378 19:39:22 <vorlon> helmut: right; I'm trying to identify a compromise here that meets your needs while also addressing the underlying reason doko made the change
379 19:40:03 <dondelelcaro> #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
380 19:40:20 <dondelelcaro> this one is still here; I think we might need to do something more specific on it, but not now
381 19:40:31 <dondelelcaro> #topic Additional Business
382 19:40:37 <bdale> none here
383 19:40:44 <dondelelcaro> as a note, I've started using usertags for the bugs
384 19:40:53 <dondelelcaro> and I've gotten rid of the useless standard sorting for ctte bugs
385 19:41:11 <wookey> keithp: it is possible to build _reasonable_ compilers (ubuntu has some). I don't think it's the best way, or a nice thing to maintain. But yes it's possible. We'll explore that in the other bug.
386 19:41:34 <keithp> wookey: thanks.
387 19:41:41 <dondelelcaro> (if someone hates it, let me know. I'll try to document it in the git eventually)
388 19:42:20 <KGB-3> \ f\ 303Don Armstrong\ f \ 305master\ f dbce33b \ 306debian-ctte\ f \ 310meetings/agenda.txt\ f remove bug which is merged with #766708
389 19:42:27 <wookey> the real issue was that _before_ that was working we got 'turned off' :-)
390 19:42:54 <dondelelcaro> anything else?
391 19:42:56 <keithp> wookey: I hope we can fix that without causing long-term pain in GCC.
392 19:43:04 <wookey> indeed
393 19:43:07 <keithp> nothing from me
394 19:43:17 <bdale> dondelelcaro: thanks again for running the meeting, Don!
395 19:43:19 <dondelelcaro> #endmeeting