On Sun, Dec 02, 2007 at 02:37:43AM -0800, Don Armstrong wrote:
> > No it doesn't, it just requires not noticing an issue -- eg, by it
> > not being brought to the tech ctte's attention at all (most
> > decisions in Debian), or by the tech ctte missing it when it is
> > (429761, 439006), or by the tech ctte leaving it lie (436096).
> These are all recent bugs, so presumably they can raised again by
> whoever thought originally that they were important.
Huh? Those are the tech-ctte's currently open bugs. There are more
examples in the archived reports for the tech-ctte. The reason there's
so few open atm is because we managed to do a purge recently, not because
we've been good at dealing with issues.
> > That's exactly wrong for the committee -- we should be around to
> > work on hard problems, and we shouldn't be spending any time at all
> > on the easy ones, which maintainers are already dealing with.
> I don't think the current case is an example of the committee looking
> for problems to resolve on it's own. Someone disagreed with the
> maintainer, and brought the issue to the tech-ctte.
I'm not particularly worried about the ctte going looking for problems;
I'm worried about us effectively rewarding the act of escalating arguments
over trivial matters, while ignoring and not dealing with important
matters.
There are a few problem areas in Debian where, IMO, the technical
committee is the right group to be stepping in and finding a solution,
but personally, I'm still a long way from seeing much evidence that we
can collectively be trusted to actually achieve a good result.
Go through the archived ctte bugs, eg. Here's my summary, divided into
bugs that I think were handled well, ones that were handled ok eventually,
after a long delay, and ones that I think are just kind of embarrassing.
(Note that these are just the bugs still assigned to the tech-ctte,
it doesn't include ones that got reassigned to other packages)
Yay!
----
266762, 266837, 270506:
assigned to ctte 20th Aug 2004
discussion up to 24th Aug 2004 resolves dispute 'til release is done
experimental fix done after freeze on 4th May 2005
273760:
assigned to ctte 28th Sep 2004
closed by non-ctte member with "This is a misplaced rant,
not a bug report." on 29th Sep 2004
343472, 345067:
assigned to ctte 7th Mar 2006
some comments and attempts at mediation
issue resolved by maintainer to submitter's satisfaction by 14th Mar 2006
402772:
assigned to ctte 12th Dec 2006
no resolution by the ctte, though some analysis and suggestions
resolved by maintainer, security team and release team to mutual
satisfaction on 16th Dec 2006
413926:
assigned to ctte 6th Mar 2007
turned into a request for advice rather than dispute resolution
on 25th Mar 2007
resolved on 27th Mar 2007
Yawn
----
316883, 329409, 341901, 342455:
assigned to ctte 7th Dec 2005
resolution to overrule maintainer drafted on 3rd Apr 2006, resolved in
favour on 9th Apr 2006
NMU performed implementing resolution dated 4th Jun 2006
accepted by maintainer 10th Jun 2006
353277, 353278:
assigned to ctte 20th Feb 2006
resolution "should remain in main" passes 9th Apr 2007
367709:
assigned to ctte 17th May 2006
closed with "no longer relevant" on 14th Jun 2007
reopened on 14th Jun 2007
vote called on 22nd Jun 2007
resolution that "a libstdc++ udeb should not be created" passes on
22nd Jun 2007
385665:
assigned to ctte 20th Sep 2006
resolution "should remain in main" passes 9th Apr 2007
Boo :(
------
119517:
assigned to ctte 14th Nov 2001
resolved on the 19th Jun 2002, as "we agree with the maintainer, the
bug reports should be closed with no action", with four ctte members
voting with a 2-all tie between the resolution and further discussion,
resolved by the chair's casting vote
107150:
assigned to ctte 1st Aug 2001
no resolution or consensus from the ctte
resolved 19th Mar 2002 by maintainer changing his mind
bug closed by non-ctte member
154950:
assigned to ctte 31st Jul 2002
vote requested by submitter 14th Sep 2002
resolved by consensus of developers by 18th Sep 2002
resolution marking the issue resolved and noting that "The Committee
regret that we have failed to get to grips with the actual
dispute or issue in the question of bug #154950 and the Gnome
transition." drafted on 23rd Oct 2002
report closed by submitter on 24th Oct 2002
341839:
assigned to ctte 16th Dec 2005
resolution to ignore previous ctte decision passed 19th Jun 2007
350739:
assigned to ctte 3rd Apr 2006
no action by tech ctte
resolved 3rd Sep 2006 with upload of cdrkit
366938:
assigned to ctte 12th May 2006
some discussion and draft resolutions proposed
closed with "no longer relevant" on 14th Jun 2007
All but one of the bugs I think were successfully dealt with didn't
require a vote, and the one that did was a request for advice rather
than a dispute resolution or overruling, and the ballot was proposed by
the person requesting the advice. Would those have been improved somehow
by the addition of a vote?
It'd be great if we wouldn't waste so much time getting to an actual
resolution when one is needed, but doing that by deciding to have a
ballot for everything as soon as possible just seems to me to be a good
way of not only losing the only things the tech-ctte has ever actually
done well, but having the ctte get more of the problems that it screws up.
> Furthermore, it seems counterproductive to complain about a decision
> on a trivial issue being a waste of time by prolonging the discussion
> of a trivial issue.
It's certainly not what I'd like to be doing, but IMO it's either a
matter of discussing it now, or dealing with the extra load resulting
from the tech ctte being seen as a good place to forward any grievance
no matter how trivial, and having the discussion when we find ourselves
hopelessly bogged down as a result.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature