Add results from latest TC Chair election

[debian-ctte.git] / meetings / 20141204 / debian-ctte.2014-12-04-18.00.log.txt

18:00:01 <dondelelcaro> #startmeeting
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.
18:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
18:00:07 <dondelelcaro> #topic Who is here?
18:00:10 <dondelelcaro> Don Armstrong
18:01:16 <bdale> Bdale Garbee
18:01:36 <keithp> Keith Packard
18:01:59 <dondelelcaro> we have regrets from aba and cjwatson
18:02:02 <vorlon> Steve Langasek
18:02:10 <dondelelcaro> I think that's everyone accounted for?
18:02:17 <dondelelcaro> #topic Next Meeting?
18:03:02 <dondelelcaro> currently the next meeting is the 18th instead of christmas day; does that still work for everyone?
18:03:16 <bdale> fine with me
18:03:21 <keithp> wfm
18:03:56 <dondelelcaro> #action dondelelcaro to ask aba and cjwatson if the 18th of December works for them still
18:04:22 <dondelelcaro> #topic #769972 New member selection process
18:04:38 <vorlon> yeah, fine with me
18:04:41 <dondelelcaro> cool
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
18:05:06 <bdale> yep, thanks for taking the lead on poking for acks
18:05:09 <dondelelcaro> no problem
18:05:20 <bdale> so our habit has been to deliberate on the list in private
18:05:26 <bdale> I assume we want to continue that?
18:05:37 <dondelelcaro> I think so
18:05:44 <bdale> if so, we should confirm that we know the list of subscribers on the private list has been updated
18:05:54 <dondelelcaro> OK
18:06:13 <dondelelcaro> I think I know where that is, so I can verify it
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
18:06:31 <dondelelcaro> #action dondelelcaro to verify the debian-ctte-private list subscribers is accurate
18:06:39 <dondelelcaro> right
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
18:07:17 <dondelelcaro> bdale: well, it has to be
18:07:23 <dondelelcaro> bdale: either during discussion, or when we vote
18:07:34 <bdale> not at all clear
18:07:43 <dondelelcaro> unless we're just going to vote Y/N on someone?
18:08:18 <bdale> last time, we discussed the nominees privately and reached consensus on who to put forward to the DPL
18:08:34 <keithp> so the public vote is a mere formality?
18:08:42 <bdale> it has been in the past
18:09:00 <dondelelcaro> hrm...
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
18:09:16 <dondelelcaro> §6.2 says "However, votes on appointments must be public."
18:09:30 <bdale> right, which is why we always hold a public vote
18:09:32 <dondelelcaro> s/6.2/6.3.4/
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
18:10:00 <vorlon> but AFAICS that only requires a public up/down vote on a given appointment
18:10:11 <dondelelcaro> we must have had this discussion last time, and I'm just misrembering our consensus
18:10:14 <dondelelcaro> OK
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
18:10:27 <dondelelcaro> yeah, that all seems reasonable
18:10:37 <Mithrandir> (you did have approximately this discussion last time too, yes)
18:10:46 <bdale> we always do .. ;-)
18:10:57 <Mithrandir> except that last time, you didn't agree on keithp vs pkern and so that bit was public, IIRC.
18:11:23 <dondelelcaro> and I probably made the same arguments too. ;-)
18:11:48 <bdale> so, to be clear, I'm all for openness and not trying to drive a particular process here
18:12:10 <bdale> I *do* want us to drive to at least 2 nominations for DPL approval with due haste, however
18:12:17 <dondelelcaro> right
18:12:41 <dondelelcaro> OK. should we close nominations?
18:12:59 <keithp> bdale: 6.3.4 seems to encourage private discussions as a process at least
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
18:13:12 <ansgar> How does the voting work if you need >1 candidate?
18:13:27 <bdale> nothing says we can't do a consensus ranking in private
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"
18:13:58 <keithp> ansgar: I think the public appearance is that individual ballots for each proposed member be voted on
18:14:13 <dondelelcaro> right
18:14:41 <dondelelcaro> yeah, either one would be OK
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
18:15:05 <dondelelcaro> does anyone object to keeping the nominations list private?
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
18:15:43 <dondelelcaro> right
18:16:00 <keithp> bdale: perhaps summarize the positive qualifications of each proposed candidate as a part of our submission to the DPL?
18:16:13 <bdale> not a bad thought
18:16:38 <keithp> Give the DPL an understanding of our reasoning at least
18:16:55 <keithp> (and the rest of the project in parallel)
18:16:59 <bdale> vorlon: any thoughts regarding this?
18:17:14 <vorlon> sorry, brain contention with work stuff
18:17:19 <bdale> np
18:17:36 <bdale> <dondelelcaro> does anyone object to keeping the nominations list private?
18:17:36 <vorlon> this is the public/private question?
18:17:45 <bdale> correct
18:17:45 <vorlon> I greatly prefer them to be kept private
18:17:49 <bdale> ok
18:17:54 <bdale> then Don, the answer is known
18:18:06 <dondelelcaro> #agreed keep nomination list private
18:18:12 <keithp> vorlon: I suggested that perhaps we summarize our reasoning for the proposed candidates in our note to the DPL
18:18:13 <vorlon> in theory people can be comfortable putting themselves forward without having the TC publically rejecting them
18:18:18 <dondelelcaro> right
18:18:24 <bdale> agreed
18:18:34 <bdale> and I like Keith's suggesting
18:18:36 <vorlon> I don't think we are under any obligation to even share the full list of candidates with the DPL
18:18:42 <bdale> we are not
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?
18:19:11 <bdale> the whole idea of publicly asking for nominations is relatively new
18:19:15 <vorlon> or maybe "proposed candidates" means just the ones we are recommending to the DPL?
18:19:19 <keithp> I volunteer to write up the summaries, iterating in private
18:19:25 <bdale> dondelelcaro: good plan
18:19:28 <vorlon> dondelelcaro: sounds good to me
18:19:36 <dondelelcaro> OK.
18:19:39 <keithp> dondelelcaro: agreed
18:19:44 <bdale> feel free to mention that deliberations will be conducted in private
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
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
18:20:46 <bdale> thank you
18:21:08 <dondelelcaro> #topic #636783 constitution: super-majority bug
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?
18:21:42 <bdale> I would be pleased with that
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
18:22:15 <dondelelcaro> sounds good
18:22:26 <keithp> one GR at a time seems like a pretty good plan
18:22:27 <dondelelcaro> I'd also be OK with tabling it until after jessie releases
18:22:34 <bdale> I'm fine with that too
18:22:40 <bdale> we have more urgent items on our agenda, frankly
18:22:50 <dondelelcaro> #agreed table #636783 until at least the GR is done, possibly jessie release
18:22:58 <dondelelcaro> #topic #741573 menu systems and mime-support
18:23:35 <dondelelcaro> keithp: I think this needed one more position for this, IIRC?
18:23:43 * dondelelcaro can't remember if that got done or not
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?
18:24:53 <dondelelcaro> OK
18:24:56 <bdale> Russ had thoughts on that .. sorry he chose to resign before this concluded
18:25:04 <keithp> any thoughts on that from the remaining members?
18:25:46 * bdale waits for the BTS to paint in his browser...
18:25:56 <keithp> I can't even reach the BTS today...
18:26:50 <dondelelcaro> hrm; that's no good
18:27:24 <bdale> so the original question was Plessy asking us to over-rule Bill's veto on the proposed policy change?
18:27:35 <dondelelcaro> right
18:27:37 <keithp> yes
18:28:50 <ansgar> Well, Plessy asked for arbitration without specifying what that means in detail.
18:28:53 <keithp> I think we can hold an up/down vote on that direct question pretty easily
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
18:29:19 <ansgar> Ah, no it specifically asks for an override later.
18:29:45 <hartmans> vorlon: It would be really cool if the TC documented that the policy process had failed and explained how.
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?
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
18:30:07 <hartmans> I think that would make me and possibly Charles feel a lot more comfortable with a decision to write policy.
18:30:19 <bdale> hartmans: good point.  it appears consensus was reached, then ignored.
18:30:20 <vorlon> keithp: I solicit a policy proposal from you
18:31:04 <keithp> I wish I could see the full bug history now...
18:31:26 <bdale> it painted for me, was just slow
18:31:58 <vorlon> bdale: if there was someone disagreeing with the "consensus" and refusing to apply it, then it wasn't consensus
18:32:23 <keithp> vorlon: 'rough consensus' doesn't mean unanimity
18:32:56 <bdale> old argument .. "group as a whole" vs "everyone agreed"
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?
18:33:32 <bdale> I think so
18:33:54 <keithp> dondelelcaro: or abstain from deciding, which is our current situation due to inaction
18:33:57 <dondelelcaro> did we ever figure out what Bill's specific objections were to the policy?
18:34:06 <bdale> I don't think so
18:34:28 <dondelelcaro> would an ultimatum be useful here?
18:34:35 <vorlon> keithp: our policy process isn't based on "rough consensus", but on a stricter definition of consensus
18:34:53 <keithp> dondelelcaro: asking Bill to explain his issues or face an override?
18:35:02 <dondelelcaro> keithp: right
18:35:15 <bdale> Bill was CC'ed in but never joined the thread
18:36:14 <dondelelcaro> yeah; that seems to be a common problem in these cases
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?'
18:36:25 <dondelelcaro> keithp: right
18:36:53 <dondelelcaro> does anyone object to that with a time limit? say 1 month?
18:36:58 <dondelelcaro> or two weeks?
18:37:00 <bdale> keithp: since you've taken the drafting lead, do you want to send that email?
18:37:04 <keithp> bdale: will do
18:37:11 <keithp> once I can reach the bug again :-)
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
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
18:37:58 <vorlon> keithp: by "override the veto", however, you don't mean applying the original proposed policy change, do you?
18:38:18 <keithp> vorlon: I can't see what that is at present...
18:38:36 <vorlon> it's the much earlier proposal that should be superseded by the much better one that you drafted ;)
18:38:42 <keithp> at this point, I can't actually recall the precise wording
18:40:38 <dondelelcaro> should we just try the debian-policy consensus method for keithp's draft in the meantime?
18:41:27 <keithp> dondelelcaro: I could bring my proposal to the policy team and see what they think, using their normal process
18:41:30 <bdale> meaning you want to learn whether the current composition of the TC has consensus around keithp's current draft?
18:42:13 <dondelelcaro> bdale: no, I meant bringing keithp's proposal to the policy team
18:42:16 <bdale> ok
18:42:25 <bdale> yes, that'd be a great step
18:42:36 <bdale> if it achieves consensus there, we'd be done
18:43:08 <dondelelcaro> vorlon: does that work for you?
18:43:59 <dondelelcaro> I'll just assume that it does
18:44:09 <vorlon> sure
18:44:09 <dondelelcaro> and if not, it can be re-raised
18:44:12 <dondelelcaro> cool
18:44:34 <keithp> vorlon: shall I stick your seal-of-approval on my proposal?
18:44:35 <dondelelcaro> #action keithp to bring his draft of #741573 to -policy for consensus building
18:44:38 <dondelelcaro> heh
18:44:43 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
18:44:52 <dondelelcaro> oh, actually, let me throw a quickie in here
18:45:07 <dondelelcaro> #topic #770789 df sizes output format
18:45:22 <dondelelcaro> this is YE OLDE SI units vs 2^10 units
18:45:40 <keithp> we're still having that discussion?
18:45:41 <dondelelcaro> and frankly, I'm just going to punt this back to the maintainer to close
18:45:50 <dondelelcaro> keithp: the bug submitter is notorious
18:46:19 <dondelelcaro> does anyone object to a quick "we decline to override the maintainer" draft for this issue? [should we even bother?]
18:46:56 <keithp> Sounds good to me
18:47:07 <ansgar> +1
18:47:36 <ansgar> Also the documentation says "print sizes in powers of 1024" for -h vs. "
18:47:42 <dondelelcaro> #action dondelelcaro to draft "we decline to override the maintainer" for #770789
18:47:46 <ansgar> print sizes in powers of 1000" for -H. Seems pretty clear.
18:47:51 <dondelelcaro> ansgar: yeah, I'm pretty sure the documentation is correct
18:47:53 <vorlon> keithp: if it's the same proposal, yes
18:48:18 <bdale> dondelelcaro: thumbs up from me
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
18:48:25 <dondelelcaro> #topic #762194 Automatic switch to systemd on wheezy->jessie upgrades
18:48:56 <ansgar> For the init upgrade I think there were three proposals.
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)
18:49:10 <vorlon> keithp: +1
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
18:50:29 <ansgar> I think two had issues with installing sysvinit in some cases.
18:50:39 <ansgar> And the last one just arrived ~2 hours ago.
18:50:48 <Mithrandir> ansgar: the xen console one?
18:51:47 <vorlon> dondelelcaro: there's a fundamental question here that we've kind of leap-frogged over
18:51:57 <ansgar> First proposal in 762194#124, I tested it in #142
18:52:12 <dondelelcaro> vorlon: whether we should actually switch the defaults?
18:52:14 <vorlon> which is whether we agree that users *should* be kept on sysvinit on upgrade, if we find a workable solution
18:52:17 <vorlon> yes
18:52:54 <hartmans> If you haven't read <5e27043707590dc20fb0b0b083912d92@iwakd.de then I recommend it.
18:52:56 <keithp> vorlon: I don't think we leap-frogged; we asked first whether that was even possible
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
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
18:53:28 <ansgar> Then there's #157 (totally untested AFAIK).
18:53:48 * dondelelcaro really should make msg-id searching work for the BTS
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
18:54:03 <hartmans> That's the one from Christian Seiler
18:54:33 <vorlon> (this was why I dissented on Diziet's last resolution on this subject)
18:54:52 <dondelelcaro> vorlon: true... I must admit that I think we should switch by default
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)
18:56:09 <ansgar> dondelelcaro: There's a patch for boot-with-sysvinit option in grub written by the systemd people.
18:56:11 <Mithrandir> dondelelcaro: cjwatson has said he'll provide a "boot with sysvinit" option in grub, afaik.
18:56:11 <dondelelcaro> does anyone on the CTTE currently think that we shouldn't be switching on default?
18:56:33 <dondelelcaro> ansgar, Mithrandir: right, that's actually why I was thinking of it. ;-)
18:56:49 <ansgar> #757298
18:56:49 <keithp> dondelelcaro: would the resulting system be bootable with sysvinit by setting the appropriate kernel command line option?
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
18:57:01 <dondelelcaro> keithp: I believe so
18:57:07 <ansgar> keithp: Yes, init=/lib/sysvinit/init
18:57:12 <keithp> dondelelcaro: Mithrandir says it would be as well
18:57:14 <vorlon> but maybe we can detect and flag it to grub
18:57:34 <Mithrandir> keithp: sysvinit in jessie ships init as /lib/sysvinit/init, iirc.
18:57:40 <vorlon> or at least flag it to the admin, and give 'install sysvinit-core' as one of the suggestions
18:57:44 <Mithrandir> so you just need to point the kernel's init argument in that direction.
18:57:57 <vorlon> AIUI, Md was already planning on doing inittab detection on upgrade
18:58:04 <keithp> Mithrandir: and make sure that sysvinit is installed
18:58:05 <Mithrandir> both systemd's and upstart's command line tools know how to speak the telinit protocol
18:58:12 <Mithrandir> keithp: it's essential in wheezy
18:58:13 <vorlon> and cjwatson was planning on providing cleaner grub selection
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"
18:58:29 <dondelelcaro> be acceptable in principle?
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.
18:59:19 <Mithrandir> unused → marked as unused in apt, so removed with apt-get autoremove.
18:59:34 <keithp> Mithrandir: as long as the autoremove is done after the system is running, that seems fine
18:59:48 <keithp> I think the concern is that the upgrade result in a system that doesn't boot
19:00:16 <bdale> right
19:00:26 <ansgar> sysvinit should not be marked as automatically installed.
19:00:31 <Mithrandir> keithp: autoremove has to be called by the admin, it's not called automatically.
19:00:43 <dondelelcaro> ansgar: yeah, I would think it wouldn't be by default either. You'd have to do it manually
19:00:45 <ansgar> Everything debootstrap installs counts as "manually installed" as far as I know.
19:00:55 <dondelelcaro> though I haven't tested that
19:01:09 <keithp> Mithrandir: sounds good
19:01:09 <ansgar> Also also did to keep sysvinit everywhere so far.
19:01:15 <ansgar> s/Also/I/
19:01:52 <dondelelcaro> ansgar: sounds good. I suppose if not, someone could provide a Suggests: sysvinit in the init package for a release
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.
19:02:19 <keithp> Mithrandir: memories of the grub->grub2 transition are painful for some :-)
19:02:45 <Mithrandir> in addition to the earlier mentioned changed inittab detection, the plan is, afaik, to detect known-problematic fstabs too.
19:03:04 <Mithrandir> keithp: sure, I'm not trying to downplay the possible pain.
19:03:29 <helmut> doesn't the alternate dependency of "init" on sysvinit-core already prevent autoremoval?
19:03:46 <dondelelcaro> helmut: dunno
19:03:59 <ansgar> helmut: No. sysvinit-core is not installed.
19:04:02 <Mithrandir> helmut: that won't prevent autoremoval of sysvinit.
19:04:31 <dondelelcaro> anyway, I think these issues can be discussed elsewhere; does anyone object to such an option?
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"
19:04:54 <dondelelcaro> do we need to keep spending people's time on non-upgrade options?
19:05:05 <dondelelcaro> s/upgrade/switch-on-&/
19:05:09 <vorlon> I would go further
19:05:33 <bdale> vorlon: ?
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
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
19:07:20 <keithp> vorlon: just as a '6.1.5 Offer advice' motion, that seems good to me
19:07:28 <dondelelcaro> I'm personally OK with that as well
19:07:35 <dondelelcaro> vorlon: do you want to draft that? or should I?
19:08:06 <dondelelcaro> (we're also running a bit over time here)
19:08:42 <vorlon> dondelelcaro: depends on how soon we expect it done
19:08:59 <dondelelcaro> well, I can start drafting it, and you can modify it
19:09:00 <dondelelcaro> heh
19:09:08 <dondelelcaro> probably would be good to get to it sooner rather than later
19:09:34 <dondelelcaro> #action dondelelcaro to draft affirmative resolution on #762194 noting #757298 et al
19:09:41 <dondelelcaro> #topic #766708 Request to override gcc maintainer changes breaking multiarch packages
19:10:32 <vorlon> dondelelcaro: that sounds like a plan :)
19:11:06 <dondelelcaro> on #766708, I think we might be too late for jessie
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
19:12:35 <dondelelcaro> I don't know how to express that in a constructive way, though
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?
19:13:37 <helmut> keithp: no. #771070
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
19:14:43 <keithp> yeah
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
19:15:21 <bdale> I haven't either .. I did see 771070, though
19:15:36 <keithp> and I even maintain a GCC package in the archive...
19:15:41 <dondelelcaro> heh
19:15:52 <keithp> (non self-hosting though)
19:16:50 <keithp> I am starting to get a sense of the politics here though, and of course both sides have valid points...
19:16:59 <bdale> my sentiment too
19:17:04 <dondelelcaro> yeah
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
19:17:41 <vorlon> well
19:17:44 <helmut> (that did happen in august)
19:17:46 <vorlon> the parties were all at a sprint
19:17:47 <vorlon> yeah
19:17:52 <dondelelcaro> oh. right.
19:18:03 <vorlon> clearly they did not all come away with the same understanding after that one
19:18:10 <Mithrandir> shouldn't have let them fly home until they were in agreement, then. :-P
19:18:12 <dondelelcaro> we never get easy solutions here! ;-)
19:18:14 <keithp> helmut: can you summarize for me what about the old solution doesn't meet 771070's desires?
19:18:28 <vorlon> AIUI everyone believed there was an agreement ;)
19:18:49 <helmut> keithp: which one is "old"?
19:18:49 <keithp> vorlon: shipping code should have been a requirement then
19:19:09 <keithp> helmut: the one used by the existing packages that actually results in working compilers
19:19:51 <vorlon> keithp: sorry, a requirement for what?
19:20:02 <keithp> vorlon: for letting them go home
19:20:08 <vorlon> well
19:20:24 <vorlon> the shipping of the code is, AIUI, the problem
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)
19:20:52 <keithp> helmut: thanks
19:20:58 <helmut> keithp: non-exhaustive
19:21:01 <keithp> sure
19:22:13 <helmut> could someone voice wookey? (he fails to register with nickserv atm)
19:22:49 <wookey> thank you
19:23:08 <wookey> the argreement was that whatever was working first would get uploaded
19:23:40 <wookey> keithp: the main disgreemnet is actually about multilib support AIUI
19:24:05 <wookey> the existing (in unstable) toolchains are one-arch each
19:24:20 <vorlon> wookey: doko has pointed out to me privately that this was never an agreement
19:24:27 <dondelelcaro> (is everyone still good on time?)
19:24:30 <helmut> reference: 20140829095214.GV19999@stoneboat.aleph1.co.uk section 3.13
19:25:10 <bdale> I just negotiated peace with my wife .. so I'm ok for a while longer
19:25:36 <wookey> vorlon: well I honestly don't understand that.
19:26:20 <vorlon> then I guess that's the crux of the misunderstanding
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)
19:26:54 <wookey> but this is very old arguement anyway. The bootstrap meet was just re-iteration 8 or so
19:27:24 <wookey> WR jessie I think the question is, will 4.9.2-X migrate?
19:27:39 <wookey> if not then there is nothing to decide on this usefully
19:28:07 <wookey> and we can punt to the more substantive 770070 (?)
19:28:31 <dondelelcaro> does 4.9.1 still carry the multi-arch cross patches?
19:28:51 <wookey> the patch to the 4.9.1-19 in jessie is the 5-liner that started this bug
19:28:53 <helmut> dondelelcaro: the jessie version carries most (minus two hunks) the sid version doesn't
19:29:01 <wookey> the patch the what is now in unstable is 5K
19:29:06 <dondelelcaro> OK
19:29:12 <wookey> there is a big difference in maintenance burden
19:29:30 <wookey> (if we decide to maintain it outside gcc)
19:30:26 <wookey> although of course versoins don;t change often in jessie, so it's do-able, just very annoying
19:30:34 <helmut> in my other mail I asked, about options for action on the gcc/jessie issue. are there any options left?
19:30:46 <keithp> wookey: it does seem like a practical solution for jessie then
19:31:27 <dondelelcaro> so I guess we can punt for jessie, but we need to address this issue more substantiatively going forward
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?
19:31:33 <helmut> i.e. are we discussing the 766708 or 771070 atm?
19:31:39 <dondelelcaro> helmut: both
19:31:40 <wookey> I don;t know...
19:31:54 <wookey> mostly 766708, I thought
19:32:05 <dondelelcaro> yeah, mainly #766708, but they're sort of inter-related
19:32:07 <keithp> helmut: I'm trying to focus on 766708 as that seems more pressing for jessie
19:32:19 <keithp> (if not, in fact, already too late)
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
19:32:56 <vorlon> and that, from doko's POV, these uploads happened over his explicit objection
19:33:13 <vorlon> (but there's no need to try to adjudicate what was or wasn't said/agreed at the sprint)
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?
19:33:55 <vorlon> if that happened, would that be an improvement from your (helmut/wookey) pov?
19:35:12 <wookey> hmm, not sure. $people still want toolchains in unstable too, so the argument remains the same
19:35:22 <wookey> but I guess it might
19:35:36 <dondelelcaro> wookey: I suppose we'd address the issues for unstable when we tackle #771070
19:35:43 <wookey> this code was happily in gcc for 2 years....
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
19:36:21 <wookey> dondelelcaro: right
19:36:42 <dondelelcaro> ok
19:37:24 <wookey> so we'd move the unstable toolchains to experimental?
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
19:37:53 <dondelelcaro> (sorry that we're being so late here)
19:38:18 <wookey> I have started a long answer to 771070, but not finished yet.
19:38:31 <keithp> from my perspective, I wonder if wookey thinks that reasonable cross compilers can be built with doko's preferred approach
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
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
19:38:49 <vorlon> since responsibility for keeping those packages buildable/installable would lie solely with the cross-toolchain maintainer
19:39:05 <dondelelcaro> #agree get agreement to #766708 around pulling the cross-packages (to experimental?), reinstate patches, etc.
19:39:17 <dondelelcaro> ok. I'm going to move on, because I'm running out of time myself
19:39:21 <dondelelcaro> #topic #750135 Maintainer of aptitude package
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
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
19:40:20 <dondelelcaro> this one is still here; I think we might need to do something more specific on it, but not now
19:40:31 <dondelelcaro> #topic Additional Business
19:40:37 <bdale> none here
19:40:44 <dondelelcaro> as a note, I've started using usertags for the bugs
19:40:53 <dondelelcaro> and I've gotten rid of the useless standard sorting for ctte bugs
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.
19:41:34 <keithp> wookey: thanks.
19:41:41 <dondelelcaro> (if someone hates it, let me know. I'll try to document it in the git eventually)
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
19:42:27 <wookey> the real issue was that _before_ that was working we got 'turned off' :-)
19:42:54 <dondelelcaro> anything else?
19:42:56 <keithp> wookey: I hope we can fix that without causing long-term pain in GCC.
19:43:04 <wookey> indeed
19:43:07 <keithp> nothing from me
19:43:17 <bdale> dondelelcaro: thanks again for running the meeting, Don!
19:43:19 <dondelelcaro> #endmeeting