--- /dev/null
+18:59:28 <dondelelcaro> #startmeeting
+18:59:28 <MeetBot> Meeting started Thu Mar 26 18:59:28 2015 UTC. The chair is dondelelcaro. Information about MeetBot at http://wiki.debian.org/MeetBot.
+18:59:28 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
+18:59:39 <dondelelcaro> #topic Who is here?
+18:59:42 <dondelelcaro> Don Armstrong
+18:59:43 <Mithrandir> present.
+18:59:47 <OdyX> Here
+18:59:48 <Mithrandir> Tollef Fog Heen
+18:59:58 <hartmans> Sam Hartman
+19:00:01 * aba
+19:00:01 <OdyX> Didier Raboud
+19:00:04 <dondelelcaro> #pingall CTTE meeting now
+19:00:10 <dondelelcaro> #ping all CTTE meeting now
+19:00:17 <dondelelcaro> hrm; never remember what that command is
+19:00:31 <dondelelcaro> bdale sent regrets
+19:00:32 <aba> I think we just miss bdale?
+19:00:35 <dondelelcaro> vorlon: ping
+19:00:44 * aba hides
+19:01:10 <dondelelcaro> vorlon is one day idle, so he might not be available
+19:02:06 <dondelelcaro> I'll just continue on
+19:02:10 <Mithrandir> MeetBot: pingall Debian CTTE Meeting now
+19:02:10 <MeetBot> Debian CTTE Meeting now
+19:02:10 <MeetBot> aba abrotman adsb babilen_ bdale berni buxy carnil cjwatson clopez_ dam Diziet dondelelcaro frozencemetery gnugr gregoa hartmans jcristau joss keithp KGB-3 kini lucas Maulkin MeetBot Mithrandir OdyX rootbeer ScottK themill tjader vorlon weasel
+19:02:10 <MeetBot> Debian CTTE Meeting now
+19:02:11 <dondelelcaro> #topic Next Meeting?
+19:02:24 <dondelelcaro> ah; you have to address it
+19:02:54 <Mithrandir> we want the next one in ~1 month's time?
+19:03:02 <aba> I think we should try to fix a regular schedule
+19:03:08 * OdyX nods
+19:03:15 <dondelelcaro> currently the next meeting is on thursday the 30th at 17:00 UTC
+19:03:19 <aba> so I don't want it fixed on UTC-times, but UTC+timesavings
+19:03:39 <dondelelcaro> right; I've moved it back and forth based on SMT/DST
+19:03:44 <hartmans> abba: that isn't a fixed schedule
+19:03:54 <hartmans> abba: as an example the offset between US and Europe changes this weekend
+19:03:57 <Mithrandir> aba: sounds sensible. We'll have fun for the four weeks of the year the EU and the US are out of sync, of course.
+19:04:20 <aba> hartmans: I don't mind for a few exceptions like "different change weekends", but in general
+19:04:28 <OdyX> thursdays are fine for me
+19:04:30 <dondelelcaro> I generally pick the last thursday in the month
+19:04:41 <aba> that's fine with me in general
+19:04:42 <hartmans> OK. understand now. And don't care so your proposal sounds fine
+19:04:43 <Mithrandir> thursdays are 50/50 hit and miss for me.
+19:04:56 <Mithrandir> so if there are other days that work, I'd prefer that
+19:05:02 <dondelelcaro> but I'm also OK moving things around slightly if that works better for people
+19:05:07 <hartmans> Thursdays are problematic for me if we're trying to do late for Europe
+19:05:07 <aba> Mithrandir: are there rules which thursdays are miss, or just random?
+19:05:16 <dondelelcaro> the main reason why I chose thursdays has changed, so I'm pretty flexible
+19:05:24 <Mithrandir> aba: pretty random, it's our the most common day for our role playing group.
+19:05:41 <aba> I generally prefer 19 local time, i.e. 18 utc in winter and 17 utc in summer
+19:05:46 <Mithrandir> Mondays are impossible for me, but other days should generally be fine.
+19:06:05 <OdyX_> Wednesdays ?
+19:06:08 <aba> for me, preference is thursday, monday, friday, tuesday
+19:06:13 <aba> OdyX_: impossible for me
+19:06:23 <OdyX_> let's condorcet it!
+19:06:33 <dondelelcaro> sure; we can do that
+19:06:39 <aba> hartmans: what is "late" for you?
+19:06:40 <hartmans> Thursday works for me, but this would be about as late as I could do Thursday and make it
+19:06:51 <aba> hartmans: one hour earlier would be ok?
+19:07:16 <aba> how about fridays?
+19:07:27 <Mithrandir> if we do a lot earlier, I can make thursdays 100%, but then you'd be looking at 0600 PST and such, which I don't really want to subject people to, unless they're happy with it.
+19:07:31 <hartmans> This would be OK, one hour earlier would be OK, but 2000 would start to run into problems
+19:07:36 <Mithrandir> (1500 CET)
+19:07:49 <dondelelcaro> I'm actually moving from PST to CST, but (-5), but I think bdale is in MST mostly, which is -6
+19:07:52 <hartmans> rather 2000 UTC
+19:07:53 <aba> hartmans: I don't want later either
+19:08:16 <aba> ok, can we check friday?
+19:08:25 <dondelelcaro> sure; I currently don't have a preference
+19:08:26 <Mithrandir> fridays should generally work for me.
+19:08:36 <dondelelcaro> why don't I just put a ballot forward, and we can condorcet it?
+19:08:43 * OdyX_ nods
+19:08:45 <Mithrandir> dondelelcaro: wfm.
+19:08:48 <dondelelcaro> ok
+19:08:51 <aba> moment
+19:08:55 <OdyX_> I propose thursdays 18 UTC
+19:09:03 <aba> OdyX_: summer or winter
+19:09:20 <aba> I prefer a date with problems for me to any date which is "really hard" for someone else
+19:09:25 <Mithrandir> northern or southern summer or winter? :-P
+19:09:34 <aba> Mithrandir: northern.
+19:09:38 <OdyX_> aba: if that becomes a question, we need to pick precise dates first.
+19:09:41 <aba> I'm not sure condorcet does that
+19:09:53 <aba> OdyX_: let's say in July
+19:10:10 <aba> because most other things move with daylight settings
+19:10:14 <Mithrandir> given we don't have keithp or bdale here, I think we should do a condorcet poll and then discuss based on that.
+19:10:23 <dondelelcaro> oh; forgot to ping keithp too
+19:10:24 <dondelelcaro> ok.
+19:10:29 <aba> Mithrandir: for a poll, works for me. for a vote, not.
+19:10:45 <keithp> I'm around
+19:11:02 <keithp> stuck in a teleconf
+19:11:05 <Mithrandir> I think dondelelcaro meant a non-binding condorcet vote. ICBW, though.
+19:11:08 <dondelelcaro> right
+19:11:26 <Mithrandir> if somebody goes "I can never make that", we'll want to accomodate that person.
+19:11:38 <dondelelcaro> we can always discuss further, I just thought it would give us a starting point for discussion
+19:11:43 <OdyX_> the simpler way is to agree on "thursdays, evenings in Europe" and fine-tune from meeting to meeting
+19:11:46 <hartmans> Hmm, this is a case where finding an option everyone can accept seems better than finding the most preferred option.
+19:11:46 <aba> did we agree with "we move it with daylight settings, and handle differences eu/us seperate"?
+19:11:59 <aba> hartmans: sure.
+19:12:10 <dondelelcaro> aba: I think that's reasonable; I've been doing that currently
+19:12:11 <Mithrandir> hartmans: inverse poll, then? Vote for the ones that don't work, pick the bottom one?
+19:12:12 <hartmans> aba: I think I was the only one who had a concern with that and withdrew it once you explained.
+19:12:27 <aba> hartmans: thanks.
+19:12:32 <Mithrandir> or something like that.
+19:12:53 <dondelelcaro> it'd be easier to just pick the ones that work, and vote the ones that aboslutely don't below FD
+19:12:54 * hartmans definitely likes 1800 british summer time though.
+19:13:12 <Mithrandir> dondelelcaro: wfm, again.
+19:13:24 <aba> hartmans: that is in general a good time for me as well
+19:13:30 <dondelelcaro> #action dondelelcaro to make informal poll to pick precise date/time of next meeting for april using condorcet
+19:13:49 <dondelelcaro> #agreed shift for DST/SMT as appropriate
+19:13:58 <OdyX_> cool
+19:14:01 <aba> dondelelcaro: should we propose suggestions for meetings?
+19:14:02 <dondelelcaro> ok; anything else on this bit?
+19:14:26 <dondelelcaro> aba: sure; I can start the thread, and put the times we talked about, and people can propose more options
+19:14:57 <aba> I think I propose here now mon, tue, thu, fri 18 british time = 19 european time
+19:15:19 <vorlon> hi y'all; oftc has decided it no longer recognizes me
+19:15:28 <aba> vorlon: nice.
+19:15:36 <aba> (and don't expect many mails from me in the next days either)
+19:15:45 <dondelelcaro> aba: cool
+19:15:59 <dondelelcaro> #action dondelelcar to include mon, tue, thu, fri 18 british time = 19 european time as options
+19:16:12 <dondelelcaro> going to move on
+19:16:19 <dondelelcaro> #topic #636783 constitution: super-majority bug
+19:16:38 <vorlon> oh I see, it's reset my password to one from years ago; good show
+19:16:39 <dondelelcaro> last meeting, aba was going to champion these going forward
+19:17:15 <aba> no news on any items from me, I'm currently collection illnesses
+19:17:18 <dondelelcaro> ok
+19:17:23 <aba> (and moving back to bed now anyways)
+19:17:31 <dondelelcaro> aba: hope you feel better soon
+19:17:32 <aba> see you next time ...
+19:17:42 <aba> dondelelcaro: I'm taking different ones to make it more interessting
+19:17:55 <Mithrandir> aba: ugh, get better.
+19:18:05 * aba waves
+19:18:10 <Mithrandir> aba: do you still want to carry those bugs forward or should we redistribute them?
+19:18:13 <Mithrandir> (before you disappear)
+19:18:14 * OdyX_ sends good waves to aba.
+19:18:34 <dondelelcaro> Mithrandir: I think anyone else who is interested in those should work with aba
+19:18:43 <Mithrandir> 'k
+19:19:00 <OdyX_> I've tried to read the bug log and forge myself an opinion, but it's horribly interconnected discussions. I'd welcome constitution diffs, shoud we do that on the git ?
+19:19:05 <aba> Mithrandir: I'm happy with both actually.
+19:19:10 <Mithrandir> oh, I didn't realise all of those actually are the same bug? At least same bug# in the agenda.
+19:19:22 <dondelelcaro> Mithrandir: right; same bug, sort of split out, but connected
+19:19:51 <hartmans> I'm happy to wait and see a proposal and discuss on list.
+19:19:52 <dondelelcaro> Mithrandir: the original idea was put forward by Diziet to use the CTTE power to propose amendments which altered the rules for how CTTE does voting and dscussion
+19:20:18 <dondelelcaro> some of the ideas are good, but some of us thought that they should be worked out using the normal process
+19:20:22 <hartmans> The super majority bug seems obvious; the others seem a bit more complex
+19:21:32 <OdyX_> I think we should have new threads with the latest proposals as constitutional diffs and decide whether we want a) to formally propose them as ctte, b) that one of us goes to -vote, c) drop.
+19:21:39 <OdyX_> … for each
+19:21:44 <dondelelcaro> sounds reasonable to me
+19:22:47 <OdyX_> I could take one of the three, starting Week 16, not earlier
+19:23:00 <dondelelcaro> OK
+19:23:15 <Mithrandir> I think splitting them makes sense too, even if we end up with a GR proposal
+19:23:22 <Mithrandir> (when discussing)
+19:23:28 <dondelelcaro> does anyone disagree with splitting?
+19:23:29 <Mithrandir> they're pretty orthogonal.
+19:24:16 <dondelelcaro> #agreed split out the constitutional amendments (clone them?)
+19:24:29 <dondelelcaro> I guess whoever wants to champion each can clone and rename them
+19:24:45 <OdyX_> I'd prefer to restart new bugs with a single summary mail, rather than a long list of mails.
+19:24:48 <dondelelcaro> and/or coordinate if multiple people are interested
+19:24:56 <dondelelcaro> up to you
+19:25:01 <dondelelcaro> you can just block that bug with the new bug
+19:25:06 * OdyX_ nods
+19:25:27 * dondelelcaro had envisioned the summary feature would help with this, but it's not really right
+19:26:05 <dondelelcaro> #action whomever/aba to clone/new+block bugs for the constitutional amendments
+19:26:13 <dondelelcaro> #topic #741573 menu systems and mime-support
+19:26:38 <dondelelcaro> I believe keithp is still discussing/going to discuss this with the policy team to try to come to consensus
+19:26:49 <keithp> dondelelcaro: I've got patches to policy and I'm still not happy with them
+19:27:10 <Mithrandir> what are you unhappy with about them? wordsmithing or content?
+19:27:17 <hartmans> have you discussed them with -policy?
+19:28:29 <hartmans> keithp: Sometimes when developing a proposal, articulalting why you're unhappy (if you can) and seeking input from those you'd like to build consensus with helps a lot.
+19:28:48 <OdyX> My current "from the sidelines" opinion pretty much aligns with plessy's, I must say.
+19:28:51 <keithp> hartmans: I'll send what I've got out then and see what people think
+19:29:00 <dondelelcaro> cool
+19:29:09 <dondelelcaro> #action keithp to send out current patches to policy for discussion
+19:29:30 <hartmans> keithp: Cool. You may get best results if you're clear what you like about it and what you don't.
+19:29:44 <hartmans> but that does sound like great progress
+19:30:03 <dondelelcaro> #topic #771070 Coordinate plan and requirements for cross toolchain packages in Debian
+19:30:07 <OdyX> keithp: does this still qualifies as "the CTTE" acting as mediator (aka is it worth us keeping the bug open) ?
+19:30:26 <dondelelcaro> OdyX: I think we should keep the bug open until the policy is resolved
+19:30:27 <keithp> yeah, it's a pretty small patch to policy, just need to get some scope around it
+19:30:43 <dondelelcaro> OdyX: even if it's just for us to re-ping every now and then
+19:31:02 <keithp> OdyX: I'm definitely not acting for ctte in my suggestions about policy changes
+19:31:26 <Mithrandir> what bothers me a bit about the issue is the whole meta thing where, AIUI, Bill pretty much just vetoed a change he didn't like, after it had gone through the normal process.
+19:31:27 <keithp> but, ctte can still perform a useful service in making sure the policy discussions actually come to a resolution
+19:31:42 <keithp> Mithrandir: agreed.
+19:31:53 <OdyX_> dondelelcaro: fair enough. But I'm not overly comfortable keeping this as a CTTE concern, while we're not exercising our powers.
+19:31:56 <OdyX_> And what Mithrandir said
+19:32:13 <dondelelcaro> OdyX_: well, at some point we might have to exercise our power
+19:32:29 <Mithrandir> I haven't dug into the -policy discussions, so it might be wrong, but if it's correct, that's worrisome. I'm not sure what would be a good way forward to resolve that.
+19:32:58 <OdyX_> dondelelcaro: if keithp is ironing something within the policy process, this means we've postponed a decision indefinitely (aka refused to act on plessy's request)
+19:32:59 <keithp> OdyX_: so, I'm doing two things at once; I'm proposing policy changes (as a DD) *and* watching the process to see if progress is still being made towards a resolution (as ctte)
+19:33:04 <hartmans> odyx: I'd like us to keep it open while we're tracking the issue, with the understanding that we plan to get involved formally if informal stuff doesn't work.
+19:33:08 <dondelelcaro> OdyX_: hopefully we won't have to, though
+19:33:17 <Mithrandir> and it's not what we're asked to rule on, so whether it's in scope for us to interfere is something we need to know/decide.
+19:33:30 * OdyX_ nods.
+19:33:32 <hartmans> If we get to a position where we would want someone to raise the issue again for us to get involved formally then we would close the bug.
+19:33:35 <dondelelcaro> OdyX_: we haven't really refused to act, because that would require a vote
+19:33:46 <keithp> Mithrandir: that's when I decided that I needed to work on this as a DD, and take actual policy changes out of the ctte process
+19:33:49 <hartmans> However my understanding is that if Keith as an individual cannot make progress here, we're then formally inloved again.
+19:33:56 <keithp> hartmans: right
+19:34:05 <Mithrandir> keithp: yeah, the problem with wielding CTTE power is it's more of a tacnuke than a scalpel.
+19:34:07 <hartmans> and that we agreedish that having try to make progress as an individual was a good thing and worth the TC waiting for
+19:34:31 <dondelelcaro> right
+19:34:38 <keithp> Mithrandir: which we would prefer to avoid in this case; but sometimes hanging the possibility over people is a useful motivator
+19:34:52 <Mithrandir> keithp: yup. carrot and stick, carrot and stick.
+19:35:10 <Mithrandir> I'm ok with waiting for keithp to make progress, as long as he feels he is making useful progress, even if it's not terribly quantifiable or externally visible.
+19:35:13 <OdyX_> I'm still not happy with this: plessy invoked the CTTE saying "the policy process worked correctly, there was an out-of-process veto, please break the tie", and we're saying "so let's re-do the policy process again, taking the veto into concern".
+19:35:43 <hartmans> I'd like to challenge the idea that refusing to act would require a vote.
+19:35:44 <keithp> OdyX_: would you like us to just vote on his proposal directly then?
+19:35:53 <dondelelcaro> OdyX_: well, the option is to have a straight up vote on that issue
+19:36:20 <dondelelcaro> hartmans: I guess I mean explicitely refusing to act; trying something else is an implicit refusal to immediately act...
+19:36:52 <hartmans> Actually, I would like us to check in with Charles and see how he feels about Keith's work. I agree with odyx that something not right here
+19:37:20 <OdyX_> well. If keithp is making progress within the policy process that can (in a timely manner) get to a resolution for the benefit of all parties, all good. But I can't resist the impression that the veto effectively had the effect of "playing with the clock" to make sure no menu withdrawal could happen for Jessie.
+19:38:11 <keithp> OdyX_: it sure ended up that way, didn't it. ctte was tied up with internal stuff and couldn't make progress on this other issue
+19:38:19 <dondelelcaro> OdyX_: could be, though that's kind of putting a bit of a bad faith spin on it.
+19:38:33 <vorlon> if the committee had been in agreement that the proposed policy changes were good, then there would have been no problem with overridding that veto
+19:38:35 <OdyX_> dondelelcaro: fair rebuttal of my argument. Point taken,
+19:38:37 <hartmans> so, if we do vote on something I'd like it to be the question Charles asked us.
+19:38:59 <hartmans> Not is the policy good, but the question of whether the veto was reasonable process.
+19:39:11 <hartmans> I.E. did d-policy get to a point where they had sufficient support.
+19:39:29 <dondelelcaro> hartmans: that's not really a question that we can answer, though; the policy process is somethign that the policy editors decide
+19:39:31 <vorlon> we've wound up where we are, with keithp trying to fix the policy, because there was not a consensus within the TC for either of the other options (reaffirm the policy changes, or reaffirm the policy revert)
+19:39:46 <OdyX_> vorlon: that's where I think we're risking overstepping: has hartmans says: plessy asked us to break the tie on whether the veto was okay or not, not for us to get involved in the policy process.
+19:40:14 <Mithrandir> OdyX_: we are allowed to answer questions with mu, though.
+19:40:24 <vorlon> I get cognitive dissonance when I hear someone say the TC is overstepping its authority with respect to policy
+19:40:29 <hartmans> dondelelcaro: Uh, why can't we consider the pprocess people followed when considering issues in our remit?
+19:40:30 <keithp> OdyX_: as the *tech* ctte, we are charged with also ensuring that the result is technically good too though
+19:40:41 <vorlon> because the TC has ultimate authority over technical policy
+19:40:58 <OdyX_> Mithrandir: "mu" ?
+19:41:02 <dondelelcaro> hartmans: we can, but we can't change policy
+19:41:19 <Mithrandir> OdyX_: the correct answer to the "have you stopped beating your wife yet?" question.
+19:41:23 <hartmans> By that do you mean we cannot change their process?
+19:41:42 <dondelelcaro> OdyX_: 無 https://en.wikipedia.org/wiki/Mu_(negative)
+19:41:49 <hartmans> Because while I don't think we can do original technical policy work as the TC, it seems fairly clear that we can decide technical policy based on original work others do.
+19:42:19 <dondelelcaro> hartmans: err, yes; sorry. I meant that we can't change the process by which the policy editors work
+19:42:29 <dondelelcaro> hartmans: we can decide technical policy, but not how they do their job
+19:42:32 <hartmans> vorlon: I wouldn't say we're over-stepping by deciding what the policy should be. I agree we have that authority.
+19:42:43 <vorlon> hartmans: right; that's what I heard OdyX_ saying
+19:43:04 <hartmans> vorlon: However, I am concerned that by deciding mostly on the technical issues, we create a climate for -policy that sucks to work in and that doing so is massively not in the project's interest.
+19:43:07 <OdyX_> I said that I was (currently) thinking about a risk though ;)
+19:44:15 <hartmans> dondelelcaro: right. But I think we can evaluate whether they followed their process as they have described it as part of evaluating a request to override their decisions brought before us.
+19:44:19 <OdyX_> anyway, I think we're in agreement that keithp's work should continue, and the bug should stay open.
+19:44:21 <keithp> hartmans: which is why I was hoping to work within the policy process
+19:45:00 <hartmans> keithp: Agreed.
+19:45:03 <vorlon> hartmans: so I don't mind a TC resolution that comments on the failures of the policy process to lead to a consensus, for instance; but the root problem is that the two policy options so far are each differently terrible and there's hard work that needs to be done to properly take all the points of view into account in a proper policy
+19:45:06 <keithp> I'll send out my (currently quite small) policy patch along with my (currently quite long) thoughts on the matter and see what the policy team thinks
+19:45:26 <hartmans> Does anyone object to me pinging Charles and asking for how he feels about our approach of having Keith work withing -policy?
+19:45:36 <vorlon> no objection to that
+19:45:37 <OdyX_> It should definitely be done.
+19:45:40 <keithp> hartmans: a fine plan
+19:45:41 <Mithrandir> hartmans: go ahead.
+19:45:49 <Mithrandir> hartmans: are you doing that?
+19:45:52 <dondelelcaro> #action hartmans to ping charles and ask about keith's work on -policy
+19:45:59 <Mithrandir> apparently. :-)
+19:46:06 <dondelelcaro> ok; let me move on to the current topic
+19:46:20 <OdyX_> .oO(Yeah, sorry for the digression)
+19:46:21 <keithp> Mithrandir: now you know not to suggest action when dondelelcaro is around
+19:46:34 <dondelelcaro> this issue is being worked on by the parties; there should be an announcement of their plan soonish
+19:47:16 <keithp> yeah, I still read mistrust in many of their messages, but I'm hopeful that some trust will be restored when everyone sees that it's more-or-less working
+19:47:19 <dondelelcaro> I proposed (and still think it's a good idea) to make a statement pointing to the announcement, congratulating everyone, and resolving this issue (#771070) once that is done
+19:47:54 <hartmans> +1
+19:48:10 <dondelelcaro> I'm going to keep reminding both parties to try to get the plan up; it's possible that it's already up and I've just missed it
+19:48:30 <dondelelcaro> well, and I should probably stop calling them both parties now
+19:48:33 <Mithrandir> I think it's a fine idea, even if it's one of those "you were asked to rule and did something else", but I think when we do that, that's often a win.
+19:48:51 <dondelelcaro> "everyone involved"
+19:49:04 <OdyX_> yeah. But we should keep the statement short to avoid possible misunderstandings
+19:49:11 <dondelelcaro> #action dondelelcaro to keep following up with #771070
+19:49:29 <dondelelcaro> #action dondelelcaro to draft possible (short) statement for voting once plan published
+19:49:36 <dondelelcaro> #topic #750135 Maintainer of aptitude package
+19:49:58 <dondelelcaro> this issue has been open for a while; aba was working on it, but it probably could use additional help
+19:50:25 <Mithrandir> is the current state somewhere?
+19:50:34 <Mithrandir> I don't recall seeing anything on -ctte about it recently.
+19:50:35 <dondelelcaro> just the bug log, really
+19:50:38 <Mithrandir> ok
+19:50:42 <OdyX> There's no visible progress from the bug since June 1…
+19:50:45 <dondelelcaro> yep
+19:51:14 <OdyX_> We have a process bug here, and should not let this happen again.
+19:52:31 <dondelelcaro> probably, but this particular issue is pretty thorny, and it really needs someone to spend substantial time looking into it and figuring out what is going on
+19:53:05 <dondelelcaro> I personally glanced at it, and didn't know what specifically to do with it
+19:53:17 <OdyX> Yeah. Easier said than done though.
+19:53:20 <dondelelcaro> so if you or someone would like to take a lead or help aba with it, that would be great.
+19:53:37 <dondelelcaro> OdyX: yeah; that's why it's sat for so long
+19:54:07 <Mithrandir> I'd be ok starting poking the involved people, but if there's been any communication whatsoever with them beforehand, I'd need to know.
+19:54:30 <dondelelcaro> I personally haven't communicated with them outside of the bug log
+19:54:46 <dondelelcaro> I'd check with aba, first, though.
+19:55:08 <Mithrandir> ok, I'll do that.
+19:55:21 <dondelelcaro> #action Mithrandir to check with aba and then ask about current state of #750135 to see what is going on
+19:55:24 <OdyX> Mithrandir: as a data point, there's https://qa.debian.org/data/bts/graphs/a/aptitude.png and the aptitude-devel@alioth list that basically has no answers from anyone involved since then (but we're in freeze too)
+19:55:35 <dondelelcaro> yeah
+19:55:44 <Mithrandir> that's a lot of bugs.
+19:55:57 <OdyX> Mithrandir: also the trend…
+19:56:16 <Mithrandir> yeah
+19:57:06 <Mithrandir> #action tfheen to talk to aba and start poking at #750135
+19:57:22 <dondelelcaro> I suspect that there's
+19:57:28 <dondelelcaro> hrm... that's not what I meant
+19:57:29 <dondelelcaro> #topic Additional Business
+19:58:08 <Mithrandir> I have one thing we need to discuss. For jessie, the release team asked us to decide on release goals.
+19:58:29 <Mithrandir> I don't think that really happened, so we should either pick up that ball for stretch or punt it to somebody else.
+19:58:30 <OdyX_> where was this ?
+19:58:41 <dondelelcaro> Mithrandir: huh; that's news to me
+19:59:33 <Mithrandir> let me find the reference
+19:59:44 <Mithrandir> it wasn't super obvious.
+20:00:46 <dondelelcaro> ok; i guess going forward, if anyone wants us to decide something, we kind of need a bug for it
+20:01:03 <dondelelcaro> it's hard to track otherwise
+20:01:14 <Mithrandir> https://lists.debian.org/debian-devel-announce/2013/11/msg00007.html
+20:01:15 <Mithrandir> yeah
+20:01:30 <Mithrandir> that one was the first kinda-ish-reference I found to it.
+20:02:14 <Mithrandir> the release team doesn't really want to do it, and having a GR for it sounds overkill, so would it be something we would like to do?
+20:02:29 <dondelelcaro> Mithrandir: oh, I think that was #727708?
+20:02:38 <keithp> dondelelcaro: yes
+20:02:59 <OdyX_> it'd be interesting to see whether we want to issue a §6.1.5 statement about technical issues we'd want see fixed for Stretch. But tuning the strength of the advice to not appear paternalistic is going to be a challenge.
+20:03:34 <hartmans> So, this would involve evaluating the release goal proposals and seeing which ones were credible enough etc?
+20:03:44 <hartmans> If so, I think that might be something we could be good at.
+20:04:10 <dondelelcaro> yeah; I suspect that if there's some specific goal that we should decide about that is controversial or involved competing options, we could assist
+20:04:14 <vorlon> I don't think it's just stating that it's credible
+20:04:17 <Mithrandir> OdyX_: 6.1.1 / 6.1.2 sounds relevant too. Or the release team would ask us to make the decision.
+20:04:34 <dondelelcaro> but otherwise, I think the release team is probably in the best position to make decisions
+20:04:35 <vorlon> because setting release goals historically means varying things like bug severities across packages, and NMU policies
+20:04:43 <Mithrandir> release goals are really a function of the bug severity policy decided by the release team, I think?
+20:05:03 <OdyX_> Mithrandir: it'd be more comfortable if the decision was explicitely deferred to us by the release team, that's for sure
+20:05:15 <Mithrandir> OdyX_: I don't think that'd be a problem to arrange.
+20:05:16 <vorlon> i.e. labeling something a release goal is giving an imprimatur that it's important to the project
+20:05:35 <hartmans> vorlon: sure... Credible was very lose. My point was mostly I'm for us being involved if we're helping work with/judge proposals.
+20:05:49 <vorlon> ok
+20:05:50 <hartmans> The plan where the TC alone decides on goals without input seems like a dreadful one
+20:05:58 <dondelelcaro> yeah; I think specifically being delegated a question by the RT is probably best
+20:06:05 <vorlon> I have no strong opinions either way on this question fwiw
+20:06:18 <dondelelcaro> but perhaps we can try out whatever the RT thinks is best
+20:06:19 * OdyX_ nods hartmans
+20:06:26 <Mithrandir> dondelelcaro: I'll talk to the RT asking them if I've understood them correctly and if so, if they could formally ask us.
+20:06:41 <Mithrandir> just so we have the t-s dotted and i-s crossed, or how that went.
+20:06:47 <dondelelcaro> yep; sounds good
+20:06:48 <OdyX_> that means proposing our help in decision-taking to RT
+20:07:03 <hartmans> Also, they could ask for input.
+20:07:08 <dondelelcaro> #action Mithrandir to tak to RT and ask if they'd like help in release goals/input/decisions
+20:07:14 <Mithrandir> we'd need to have reasonable turnaround time in that case, of course.
+20:07:17 <hartmans> rather than just deferring the decision. So they would be able to adjust our input without a second resolution
+20:07:28 <Mithrandir> hartmans: yeah. That's up to them, really.
+20:07:31 <dondelelcaro> ok; one more thing; who is going to be at debconf?
+20:07:33 <vorlon> Mithrandir: ṫɨ
+20:07:40 <dondelelcaro> I actually will not be able to make it, unfortunately
+20:07:41 <hartmans> I have a more thing after that.
+20:07:52 <Mithrandir> I might or might not, I'm not sure yet.
+20:07:58 * hartmans plans to be at debconf but needs to talk to the other manager at Painless Security and get approval next week.
+20:08:02 <dondelelcaro> but I will endeavor to telecommute as much as possible
+20:08:19 <vorlon> I haven't started planning for DebConf; there's a high probability that I'll be there
+20:08:20 <Mithrandir> hoping to, but we're doing a cross-US drive in september, and I'm going to SF before then, so I might be running out of days in August.
+20:08:36 <OdyX_> I'll be there.
+20:08:51 <hartmans> How likely is it people attending debconfg will attend debcamp?
+20:08:53 <Mithrandir> it's vaguely more likely I'll be at debcamp.
+20:09:32 <OdyX_> I'm likely to miss DebCamp, go to CCCamp first, then DebConf.
+20:09:38 <hartmans> After debconf I'd like to discuss the busybox mail
+20:09:43 <vorlon> I don't have any plans to attend DebCamp
+20:10:04 <hartmans> or rather after this discussion of debconf; don't want to wait until September
+20:10:49 <dondelelcaro> I think we can move on to the busybox thing, unless there's something else?
+20:10:59 <OdyX_> okay. so that'd be hartmans, vorlon & odyx @ DebConf for sure, all others undecided, right ?
+20:11:20 <dondelelcaro> yep; with me a no.
+20:11:37 <hartmans> So, we've been asked by the (former)? busybox maintainer to help him understand why his changes were rejected by some combination of -botot and the RT.
+20:11:38 <dondelelcaro> (too many weddings)
+20:12:11 <hartmans> I went back and asked him what help he wanted giving a couple of options and got a response that I could'nt understand.
+20:13:19 <hartmans> I think this is a case where I'd rather help someone understand something than say get a request to override (or override for a point release) and where reducing stress is good if we can.
+20:13:26 <hartmans> But I'm not sure what the best course of action is.
+20:14:00 <hartmans> One of the simpler approaches is that someone could explain why in the RT's place they might have rejected the changes--focusing not on what happened here but on explaining why that might be a reasonable thing to do.
+20:14:17 <OdyX_> my understanding is that RT and d-i insist on keeping all changes targetted at jessie during the freeze as minimal as possible, especially in the freeze. busybox being in the -boot realm, KiBi monitors and ack/nacks the changes there. The changes that Mike wants in Jessie are mandatory in his eyes, but not in the RT or KiBi's eyes.
+20:14:20 <hartmans> I believe I could do that, although I think there are others on the TC who probably have more release engineering experience than I do.
+20:14:33 <hartmans> But would be happy to write such mail if no one else wants it and we think it valuable
+20:15:02 <hartmans> nod.
+20:15:08 <hartmans> My argument were I to write such a mail would be that
+20:15:49 <hartmans> busybox-static being totally broken is not the end of the world. Yes, it's one recovery option, but it's a nice to have not a must have. You've got live dvds, chroots, other ways of doing recovery
+20:16:09 <hartmans> where as busybox is very critical. And being able to know that when you do an upload busybox is going to build is also critical.
+20:16:39 <hartmans> and any change to the build system can introduce ftbfses/can be tricky. An example of that is that it took him several tries to get the build-depends right.
+20:17:12 <hartmans> and so, a reasonable person might conclude it would be better to detect after the fact busybox-static being build in a broken environment and rebuild than to futz with the build system in freeze
+20:17:45 <OdyX_> I think that's pretty much aligned with RT and KiBi's reasoning, even though they might not have spelled it out as clearly.
+20:17:49 <hartmans> I don't know that's the rationale behind the decision that was made, but that's a rationale that I think a resanoble release engineer could have made here
+20:18:12 <vorlon> well, I'm not sure if what you want here is engagement on the technical substance, but my counterargument there is that this is a breakage that can be arbitrarily reintroduced in a security update
+20:18:48 <vorlon> yes, reasonable people can reach the same conclusion that the RT did in this case
+20:18:55 <hartmans> vorlon: Yeah, true. If you reject the change you run the risk that you'll have to keep rebuilding security updates until you get a busybox-sattic that's good.
+20:19:28 <dondelelcaro> yeah; maybe just making these arguments so that it's a clear decision would be enough?
+20:19:30 <hartmans> You'd presumably be arguing that having a security update to busybox go throguh even if the resulting busybox-static is useless is better than having the security update ftbfs because busybox-static failed its test.
+20:19:47 <Mithrandir> I'm slightly worried about process again. We can't expect people to know all the teams and how they interact and such, but working around broken buildds instead of just talking to the buildd people (which it didn't look like he tried?) makes me worried about possible fragility in the solution.
+20:20:02 <hartmans> But vorlon's counter argument is the argument in favor of accepting the change.
+20:20:54 <dondelelcaro> hartmans: right; I meant to include the counter arguments so that Michael knows that the RT and KiBi (and the Security Team?) are aware of the issues, and are OK with dealing with them
+20:21:04 <vorlon> Mithrandir: historically, correct contact information for buildd maintainers is hard to come by. How would I find that today from e.g. buildd.debian.org?
+20:21:06 <OdyX_> I think we could reasonably ask Mike to reduce his patch to a small, reviewable, and doing-only-this patch.
+20:21:35 <Mithrandir> vorlon: afaik it's been the arch lists, historically.
+20:21:51 <weasel> debian-wb-team@ldo might work. it's not, strictly speaking, the right contact, but ...
+20:21:56 <dondelelcaro> OdyX_: though before that, I'd suggest that KiBi and the RT be approached to ask if they'd accept it in principle to avoid busy-work
+20:21:56 <hartmans> odyx: We can, but we've been asked to provide understanding here, not to fix the problem.
+20:21:57 <Mithrandir> vorlon: but, reasonable point.
+20:22:06 <dondelelcaro> true
+20:22:07 <OdyX_> dondelelcaro: yeah.
+20:22:20 <vorlon> Mithrandir: yes, those lists are a /completely/ non-effective method of contacting anyone who can fix the buildds
+20:22:24 <hartmans> Often, when you're frustrated enough to be dropping involvement in something, understanding the other side is actually more valuable to reducing frustration than fixing the technical problem.
+20:22:31 <dondelelcaro> hep
+20:22:34 <Mithrandir> heck, mailing -devel going "this is broken, I need this fixed, can somebody tell me how to get in touch with whoever maintains buildds A, B, C" would probably have worked.
+20:22:37 <dondelelcaro> s/h/&y/
+20:23:00 <OdyX_> so we've just demonstrated buildd-administrators are not reachable anywhere each of us expects them to be found :)
+20:23:24 <dondelelcaro> ok; we're a bit over time; I think for this, hartmans approach is good... and there are also underlying technical issues here which could also use some ironing
+20:23:41 <dondelelcaro> does anyone disagree with having hartmans go forward with trying to summarize?
+20:23:51 <OdyX_> Mithrandir: that said (problem can be fixed by upgrading buildd chroots), I think "problem can be flagged at build-time" is also a good engineering practice…
+20:23:52 <vorlon> no
+20:24:14 <OdyX_> no, all good.
+20:24:17 <dondelelcaro> #action hartmans to summarize and try to explain the concerns re busybox-static et al.
+20:24:18 <Mithrandir> please do.
+20:24:22 <dondelelcaro> ok; anything else?
+20:25:03 <dondelelcaro> #endmeeting
\ No newline at end of file
projects / debian-ctte.git / commitdiff