Re: Bug#797533: New CTTE members
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
Reply to: