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