[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: