On Wed, Sep 09, 2015 at 10:31:24PM +0100, Wookey wrote: > +++ Steve Langasek [2015-09-09 12:17 -0700]: > > On Wed, Sep 09, 2015 at 05:30:03PM +0100, Wookey wrote: > > > So what I learned from this is that, as currently operating, the > > > committee is incapable of making quick 'overrule unreasonableness' > > > decisions. My overriding impression was that those involved simply did > > > not have the time available that would be be needed to enable that. > > No, what you see here is that the TC did not agree with you that the > > maintainer's action was unambiguously unreasonable under the circumstances. > Well, maybe. Maybe there were discussions to that effect I didn't see.
FWIW, I read that bug at the time; though the only evidence I see off hand is that I retitled it about a week after the jessie freeze began. Hmm. Aha, it was off-list, but still in my email archives! This was on the 17th Nov, so AIUI it was already too late for anything useful, but FWIW my response was: --- Good grief. The timeline of that bug is: Filed Date: Sat, 25 Oct 2014 05:58:36 +0200 Maintainer responds the next day (on a weekend), dropping from serious to wishlist Date: Sun, 26 Oct 2014 14:04:05 +0100 Ten minutes later, submitter bounces the severity back to serious, calls the change "hostile" Date: Sun, 26 Oct 2014 14:15:35 +0100 An hour later, Matthias bounces the severity back to wishlist Date: Sun, 26 Oct 2014 15:15:36 +0100 Thirty-five minutes later, tech ctte is officially called in Date: Sun, 26 Oct 2014 15:51:00 +0100 I don't see any serious attempt to work with the maintainer there. >From what I can tell, doko's mistaken in saying it's not a release goal. CrossToolchains is listed on https://wiki.debian.org/ReleaseGoals and the link there recommends behaviour that the changes break. Release goals justify an important severity bug, not a serious one though, so the severity bouncing seems marginally abusive. doko didn't mark the bug as wontfix, just wishlist, so I don't see any indication that he doesn't think the bug's worth fixing. That leaves the question of prioritising the fix (in particular pre- or post- jessie), and what form the fix should actually take. If it were me, I'd be inclined to: - reset the severity to important, since it's a release goal - recommend doko resolve it by: (a) reverting the change, (b) updating the wiki page with correct documentation on how to do multilib cross-builds (particularly addressing the issue that packages are apparently uninstallable?), or (c) inviting Wookey or similar to co-maintain that aspect of the packaging (and deal with bug reports due to it) - criticise Helmut for inflating the severity and invoking the ctte so quickly rather than working with doko As far is jessie is concerned, it seems like the release goal mostly missed the boat? All the cross-gcc* packages are blocked by the freeze, and have RC bugs filed by doko, without any response from the maintainer... So it seems like a shame to miss jessie, but I'm not seeing any huge reason why it should bypass the freeze. The timing wrt the freeze seems to be: - 22nd Oct: cross-gcc-* packages make it into unstable - 24th Oct: cross-gcc-defaults makes it into unstable - 24th Oct: doko uploads change to gcc-4.9 - 24th Oct: doko files bugs against cross-gcc-* packages - 25th Oct: last day for uploads to unstable to hit before freeze which again says to me that the cross-gcc-* stuff was left way too late, but also dropping support for that method of cross-building gcc at almost the last minute before the freeze seems a bit unreasonable. I don't see anything here that justifies overruling the maintainer though. Maybe if I were the maintainer (heaven forbid) I'd do things differently, but that's barely justification for offering advice, let alone setting policy or overruling the current maintainer. --- I guess at this point I'd summarise it as three things: - Trying to get a release goal done by uploading to unstable a couple of days before the absolute deadline for uploads to unstable is a bad plan. - That issue was actually pretty complicated, and not one that's going to come to an obvious consensus in a couple of days, so expecting an effectively instant endorsement of your view (either by doko being convinced by your bug, or the ctte overruling doko within the 24 hours or so you'd need in order to get a reversion into unstable) wasn't really reasonable. Again, a good reason to do things well before the freeze. - Given they weren't going to overrule immediately, and thus cross-gcc wasn't going to make jessie, it would have been good for the ctte to have actually said "we're not going to overrule doko in time for the freeze" within 24 hours of the issue being referred -- eg, by having an immediate vote where 3+ members vote for further discussion over overruling. This has never happened before, and the request was at the same time as the "preserve freedom of choice of init systems" GR was under discussion, so not real surprising nothing happened here either, and again, a good reason to do things earlier, no? > > But you are asserting that the reason for this > > is that the TC is unable to act quickly to overrule. This is not the case; > > there is historical precedent for quick overrules by the TC where there is > > actual agreement that this is appropriate. Having an immediate vote (that often results in FD) everytime a new ctte bug gets filed seems like a plausible approach to ensure people get a quick initial response from the ctte though? eg: Bug#776708 arrived two hours ago. Let's vote! Resolution: overrule gcc maintainer for cross-gcc-support Options: - Overrule maintainer (3:1 majority) - Leave as is -- decline submitter's request - Further discussion Votes: Alice: Overrule > FD > Leave as-is Bob: FD > Leave as-is > Overrule Carol: FD > Leave as-is > Overrule Dave: Leave as-is > FD > Overrule Emma: FD > Overrule > Leave as-is Outcome beyond doubt 24h later: FD > * (4:1) would not make a decision or require too much immediate thought on behalf of the ctte members -- heck even the bug log wouldn't have been very long at that point -- but it would probably give the submitter and maintainer a good feel for where they stand ("Oh, it's not obvious to everyone sane that I'm write and they're wrong? Huh."). > (not forgetting that I didn't raise it to the TC (Helmut did)). Mind > you, I don't know what else he could have done under the > circumstances except suck it up. I don't think anything else could have been done at that point. In retrospect, I think the best fix is to get things into unstable and testing sooner, rather than later, and it looks like that's already happening for stretch, right? Cheers, aj
