Re: Question to all candidates
Scott James Remnant wrote:
The current Technical Committee is inactive; in the past two years they
have only made two rulings:
* 2004-06-24 Bug #254598: amd64 is a fine name for that architecture.
* 2004-06-05 Bug #164591, Bug #164889: md5sum </dev/null should
produce the bare md5sum value.
Do you believe that the tech-ctte should be relatively inactive? Or do
you believe that an inactive Technical Committee is a bad thing?
If the latter, do you propose (as they would be your delegates) to make
any changes to the current make-up of the committee.
Oh, on rereading I guess I should note explicitly that the tech ctte
aren't the DPL's delegates in any way, shape or form. Anyway.
In one sense an inactive technical ctte should not be an issue: our
constitution allows inactivity on anyone's behalf, and so we should be
able to cope with that. And, indeed, mostly we do.
I think it's actually bad in two ways though: one is that it sets a bad
example for other groups within Debian, the other is that as one of the
recommended ways of resolving technical disputes it makes it harder to
make decisions.
I don't think the membership of the ctte is the major problem, instead I
think it's more an issue of the tradition that's built up of how and
when the tech ctte should act. Traditions like that aren't easy to
change, though (that's why we call them traditions), and since the
technical ctte is designed as one of the counterbalances to a
dictatorial/tryannical DPL that's not something the DPL can resolve on
his/her own prerogative.
I think the easiest way of breaking up what I see as the bad traditions
the tech ctte have established over the years is with some fairly
serious shock treatment. I think the following shocks would work:
* changing the membership completely, ie having everyone on the
tech ctte step down, and not immediately step back up, even if
they're (otherwise) the most suitable candidate for the role.
* changing the informal "eligibility" requirements, from being
experienced and respected to being active and involved, by
solely or mostly appointing active delegates to the positions
* having the position of chair rotate amongst ctte members every
two to three months
* having the normal process for handling of issues before the
tech ctte be the ctte chair explaining his/her opinion
immediately, and that being authoritative unless someone else
on the ctte demurs within about a week
* potentially establishing a tradition of between one and three
people stepping down from the tech ctte and being replaced
each year
I'm not sure if all of those are possible and some might not be
desirable; but hopefully there are enough there that if some of the
shocks don't happen, the remainder are enough to resolve the tech ctte
related problems in the project.
I think good roles to have represented on the tech ctte include
ftpmaster, buildd maint/ports support, security support, QA, release
manager, policy maint, webmaster, listmaster, BTS admin, dpkg/apt
development, debian-installer development, toolchain (glibc, gcc, etc)
suppport, and similar roles that the project as a whole depends on. The
benefit of this is that people involved in those roles generally have a
good idea of what's going on across the project (since whenever they
break anything, people crawl out of all sorts of obscure nooks and
crannies to complain :), and the project already relies on them, so
presumably trusts them to not screw it around too much.
(Given the restrictions on how many people can be in the tech ctte at
any one time, it's fortunate there're a few people that individually are
involved in many of those roles. :)
Anyway, like I said, this isn't something the DPL can even come close to
doing unilaterally; so my approach, if elected, will be to talk to
various people in those roles to see if they'd be willing to work on a
reconstituted tech ctte, and to see what concerns the existing tech ctte
have about the prospective new team and ensure they're addressed, so
that we can aim for an amicable handover that at least satisfies the
people directly involved if not everyone working on Debian.
Cheers,
aj
Reply to: