Re: Bug#797533: New CTTE members

[Anthony Towns]

On Mon, Sep 14, 2015 at 09:37:28AM -0400, Sam Hartman wrote:
> What I'm hearing is that there seems to be general support for TC
> members calling for quick votes in cases like this.  If I were doing it
> I'd probably give 24 hours to comment on an interim ballot and then do a
> CFV.

It seems to me that the only way you'd get a ballot like that out quickly
is if there's a template you could easily fill out, that's "good enough"
for, say, 80% of issues. If you're coming up with something within a
day of an issue being filed, I don't think it's reasonable to try to
have a detailed background of the issue in the ballot, for instance.

A) agree with the bug:

 A.1) Under 6.1.2 of the constitution, the committee resolves the dispute
  between developers [...] (as maintainer of [...]) and [...] (as
  maintainer of [...]) by determining that:

   * [the priority of package ___ should be ___]
   * [/usr/bin/___ should be owned by package ___]
   * [bug  should be fixed in package ___]
   * [package ___ should be maintained by ___]
   * [...]

 A.2) Under 6.1.3 of the constitution, the committee accepts the
  delegation by developer [...] of the right to decide [...], and
  determines [...].

 A.3) Under 6.1.4 of the constitution, the committee overrules the
  developers involved, and requests the following technical course
  of action be undertaken:

   * [package ___ should be reuploaded with the following patch
  applied, or equivalent functionality: ...]
   * [package ___ should be reuploaded with the following patch
  reverted: ...]
   * [...]

 A.4) Under 6.1.5 of the constitution, the committee offers the following
  recommendation for dealing with the issue raised, but at this point
  leaves the final decision in the hands of the developers involved:

   * [the priority of package ___ should be ___]
   * [/usr/bin/___ should be owned by package ___]
   * [bug  should be fixed in package ___]
   * [package ___ should be maintained by ___]
   * [package ___ should be reuploaded with the following patch
  applied, or equivalent functionality: ...]
   * [package ___ should be reuploaded with the following patch
  reverted: ...]
   * [...]

B) decline the bug:

 B.1) The committee think the issue raised requires further discussion,
  but that the project would be best served if this took place via
  [the bug log | debian-policy | the  mailing list | ]
  rather than involving the committee directly at this point in time.

 B.2) The committee endorse the actions of [...] as the responsible
  maintainer and as such decline to overrule their decision.

 B.3) While not endorsing the decisions of [...] regarding this issue, the
  committee accepts that they were not unreasonable, and bearing in mind
  that, in general, individual developers have the right to "make any
  technical or non-technical decision with regard to their own work",
  declines to overrule the decision in this case.

For bug escalations where users think a developer's done something
wrong, A.3, A.4, B.1, B.2 and B.3 would be reasonable.

For conflicts between developers with overlapping jurisdictions, A.1, A.4,
B.1, B.2 and B.3 seem reasonable (and I don't think A.3 is necessary).

For the rare case where a DD delegates a decision to the ctte, A.2 or
B.1 would be the only reasonable options I think? If FD won initially,
and discussion resulted in consensus that the DD went ahead with, B.2
could become an option I guess.

If someone asks the ctte for advice on a topic before there's an
entrenched disagreement (!) I think FD and B.1 would be sufficient
alternatives for an initial vote?

(Hmm, having templates like this might make it easier for people to
understand how the ctte can actually help, maybe...?)

> I understand there are community members who want to go further than
> that and have automatic votes, etc.

FWIW, to me "automatic" means "quick", "easy", and "likely to actually
happen"; while "manual" means "slow", "painful", and "likely to be
forgotten pretty frequently". If you end up with a process that turns
out quick, easy and likely to actually happen, but requires people to
do manual steps, I'm likely to call it "automatic" anyway. ;)

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug#797533: New CTTE members

[Anthony Towns]

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 

Re: Bug#797533: New CTTE members

[Wookey]

+++ Don Armstrong [2015-09-10 09:57 -0500]:
> On Wed, 09 Sep 2015, Wookey wrote:
> > Well, maybe. Maybe there were discussions to that effect I didn't see.
> > In that case fair enough. The impression given was of a somewhat slow
> > process and members not having time to review the situation, so
> > preferring to punt, and not distinguishing between the immediate issue
> > for jessie and the general issue for stretch onwards.
> 
> Have the notes from the discussion at debconf been published yet?

Not quite, but I'm working on them right now (I only got back a
few days ago). Should be out imminently (after giving a chance to comment
- I don't want to be accused of falsification again).

> I'm afraid that this issue is not going to be resolved in time for
> stretch either unless things start moving.

Things have already moved quite lot, and the agreement at debconf was
to do it doko's way for stretch so for practical purposes it is
resolved for now.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Re: Bug#797533: New CTTE members

[Don Armstrong]

On Wed, 09 Sep 2015, Wookey wrote:
> Well, maybe. Maybe there were discussions to that effect I didn't see.
> In that case fair enough. The impression given was of a somewhat slow
> process and members not having time to review the situation, so
> preferring to punt, and not distinguishing between the immediate issue
> for jessie and the general issue for stretch onwards.

Have the notes from the discussion at debconf been published yet?

I'm afraid that this issue is not going to be resolved in time for
stretch either unless things start moving.


-- 
Don Armstrong  http://www.donarmstrong.com

This isn't life in the fast lane, it's life in the oncoming traffic
 -- Terry Pratchett

Re: Bug#797533: New CTTE members

[Don Armstrong]

On Thu, 10 Sep 2015, Wookey wrote:
> +++ Don Armstrong [2015-09-10 09:57 -0500]:
> > Have the notes from the discussion at debconf been published yet?
> 
> Not quite, but I'm working on them right now (I only got back a few
> days ago). Should be out imminently (after giving a chance to comment
> - I don't want to be accused of falsification again).
> 
> > I'm afraid that this issue is not going to be resolved in time for
> > stretch either unless things start moving.
> 
> Things have already moved quite lot, and the agreement at debconf was
> to do it doko's way for stretch so for practical purposes it is
> resolved for now.

Excellent; thanks for working through this.

-- 
Don Armstrong  http://www.donarmstrong.com

Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

Re: Bug#797533: New CTTE members

[Don Armstrong]

On Thu, 10 Sep 2015, Sam Hartman wrote:
> Sure, and I'd also argue that someone on the TC should believe that an
> option other than FD should win before holding a vote.

If anyone feels that an option besides FD could carry quickly, they
should write a ballot quickly, and propose calling for votes. Indeed,
that precise event has happened: see #770789 for an example.

In the multi-arch case, I personally would have voted FD above all other
options had a ballot been proposed immediately, and I suspect at least
two other people would have also.

-- 
Don Armstrong  http://www.donarmstrong.com

listen, what you do in the privacy
of your neighbour's house while they're away
is your own business
 -- a softer world #511
http://www.asofterworld.com/index.php?id=511

tech-ctte decision/feedback speed (was: Re: Bug#797533: New CTTE members)

[Anthony Towns]

(bug dropped, subject changed)

On Thu, Sep 10, 2015 at 01:32:16PM -0400, Sam Hartman wrote:
> > "josh" == josh   writes:
> josh> That's not a bad plan, actually.  The three standard options
> josh> could be, in effect, "preliminary injunction against the
> josh> maintainer to avoid immediate harm, but we still need to talk
> josh> about this more", "dismissed as completely inappropriate to
> josh> have taken to the TC at all", or "we need further discussion
> josh> before we can even offer an opinion".
> Sure, and I'd also argue that someone on the TC should believe that an
> option other than FD should win before holding a vote.
> We don't need more process for process's sake.

In this case the process wouldn't be for process's sake, though. One of
the failures with #776708 was that it was urgent and there was simply no
feedback from the ctte that there was disagreement blocking a quick
resolution.

> But having something like this in place and an understanding on the TC
> that if k TC members (probably k = 1) feel this is reasonable calling
> for such a vote is a fine thing to do.

I think if the submitter thinks the issues is urgent ("freeze deadline in
24 hours! help!") that should be enough; even if none of the TC think an
immediate decision is actually reasonable, having an actual vote that
documents that would still be helpful.

I tend to think "automatic" processes are better than ones that actually
require humans to think about them. In this case, if ctte members have
to come up with an answer to "is immediately overriding the maintainer
reasonable?", then it seems easier to do that in response to a thoughtless
automatic vote, and also more transparent to do it by voting than simply
not doing anything as a result of deciding one way.

Heck, maybe make the process be: urgent issues get voted on a day after
they're filed, and every issue gets a vote proposed one day after the
monthly meeting. FD is always a valid option, but members voting for FD
should make it clear what they think actually needs further discussion.

(In #766708's case, I would probably have personally voted "decline to
overrule maintainer" above FD for #766708 immediately, given the freeze
deadline likely made FD an effective rejection anyway)

Cheers,
aj

Re: Bug#797533: New CTTE members

[Wookey]

+++ Didier 'OdyX' Raboud [2015-09-02 14:53 +0200]:
> 
> One problem we have, I think, is that we allowed issues to get stalled 
> for quite long periods of time [0]. 

> What I really would hope new TC members could bring is more an ability 
> to react in bursts rather than a commitment to spend a fixed amount of 
> hours per week/month. 

A little perspective from an outsider who had cause to see the
committee's working this year:

Before interacting I had assumed that the CTTE was a powerful and
effective body within debian, to which you could go if things had gone
really badly wrong, and that if something was brought to the committee
they would take a look quite quickly and (in the case of something up
against the release deadlines) make a quick decision on whether X was
out of order or not.

It turns out the process is nothing like that, and indeed almost
completely useless for such situations. In fact nothing happens until
a monthly IRC meeting, where a backlog is considered. No-one has
looked at the new issue in enough detail to form an opinion, and ways
are looked for to see if the committee can avoid ruling by asking for
other forms of mediation.

This makes perfect sense from the committee POV, because making a
decision involves properly understanding the issue, which requires
time (possibly quite a lot of it), and quite often, asking the
parties to go and sort this out themselves is a sensible choice.

In the case of #766708 this procedure was not effective. The
maintainer's use of veto power days before the freeze effectively went
entirely unchallenged, and the complainants had to do a pile of work
to work around it and get something workable in jessie.

Ian put it quite well in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766708#305

The choice in the related bug #771070 to make us go and argue it out
amongst ourselves was reasonable, and in the absence of the investment
of a lot of time to properly understand the issue, probably the only
realistic choice. So the process is working OK there, although there
has still been disappointingly little substantive discussion of the
_technical_ arguments, as was observed at debconf.

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.
Maybe no-one has enough time, and even if one or two members did, the
voting system means that quick decisions would require more than half
the members to be able to invest the necessary time for understanding,
which is even less likely.

So it would appear to be the case than a quick response is simply not
possible within our current structures? That is something to
communicate to complainants because I'm not sure it's widely
understood.

Don't know if that's useful info or not - you probably knew all that,
but hopefully it gives a little external perspective.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Re: Bug#797533: New CTTE members

[Sam Hartman]

> "Wookey" == Wookey   writes:

Wookey> +++ 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.

Wookey> Well, maybe. Maybe there were discussions to that effect I
Wookey> didn't see.  In that case fair enough. The impression given
Wookey> was of a somewhat slow process and members not having time
Wookey> to review the situation, so preferring to punt, and not
Wookey> distinguishing between the immediate issue for jessie and
Wookey> the general issue for stretch onwards.

For what it's worth, I'd like to gain confidence that we could act
quickly with a complex technical issue like this one if we chose to.
I'd like to afirm my confidence that if something like this came up
where we had little time, we'd do the work necessary to evaluate whether
we needed to act quickly.

I was an outsider at that time, and from that outsider's standpoint, I
could not see the TC making the evaluation about whether quick action
was required.
I'm not saying it didn't happen, just I didn't see it.

As a TC member now, I'd like to better understand how we'd do that.

In terms of qualifications for new members, I'd like to see whether we
want to be able to act quickly in situations like this when required,
and if so, whether that impacts who we are looking for.

--Sam

Re: Bug#797533: New CTTE members

[Nikolaus Rath]

On Sep 09 2015, Steve Langasek  wrote:
> 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.

Is that disagreement captured somewhere? Looking at #766708, the bug was
filed on Oct 26th and from then until Dec 16th (at which point it was
too late for jessie) we have the following emails from ctte members:

- one email from Don asking Matthias for more information (but he got no
  reply).

- one email from Ian (who, according to his later emails was certainly
  not opposed to overwriting the maintainer)

- One question from Colin that I can't interpret as either agreement or
  disagreement, but it was answered by Wookey and got no further
  response.

- One skeptical question from Don on Nov 19th

- Another email from Don about long-term consequences that he explicitly
  says is not related to the jessie decision


So the only mail that could be interpreted to signal disagreement in the
ctte is this one:

,
| From: Don Armstrong 
| To: Helmut Grohne , 766...@bugs.debian.org, Debian GCC 
Maintainers , woo...@debian.org
| Subject: Re: Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross 
building
| Date: Wed, 19 Nov 2014 16:41:49 -0800
| 
| On Tue, 28 Oct 2014, Helmut Grohne wrote:
| > I have to admit that the code is not exactly lightweight. I do
| > understand the desire to get rid it and asked that a ctte ruling does
| > not apply beyond jessie for that reason.
| 
| Are people who are doing cross-building like this actually using the
| code which will be in jessie? I (perhaps naïvely) would expect them to
| be primarily using the code in unstable, and maybe at a late stage of
| bring-up rebuilding all of stable.
`


Note that only three members of the ctte actually voiced anything at
all. To me this looks a lot more like the ctte not having enough time
rather than the ctte being stuck in some intractable technical
disagreement that prevents them from taking any action.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Bug#797533: New CTTE members

[Steve Langasek]

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.
There was a substantive technical dispute between maintainers about how
certain related packages were being handled in the archive; this is not
solved by summarily overruling the maintainer of one of the packages.

If you conclude from this that raising the issue to the TC was not an
effective way to see your grievance addressed under those circumstances,
I won't disagree with you.  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.

That said, if developers have expectations of the TC that don't match
reality, that seems worth addressing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Bug#797533: New CTTE members

[Wookey]

+++ 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.
In that case fair enough. The impression given was of a somewhat slow
process and members not having time to review the situation, so
preferring to punt, and not distinguishing between the immediate issue
for jessie and the general issue for stretch onwards.

I don't mean to have a go at the CTTE, or go over it all again. I was
just trying to explain that the process was nothing like I had
imagined it would be, and that this suprised me. Having seen how the
meetings operate I do now understand why it is like it is. 

> If you conclude from this that raising the issue to the TC was not an
> effective way to see your grievance addressed under those circumstances,
> I won't disagree with you. 

(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.

> 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.

OK. Fair enough. I do only have one data point :-)

> That said, if developers have expectations of the TC that don't match
> reality, that seems worth addressing.

Well, I've had my expectations addressed. Not sure about everyone else :-)

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/