On Mon, Feb 06, 2006 at 04:30:46PM -0500, Raul Miller wrote:
> On 2/4/06, Anthony Towns <aj@azure.humbug.org.au> wrote:
> > (1) Rotating the tech ctte chair
> >
> > Changing chairs every two months would mean everyone would be chair over
> > the course of the year; helping ensure that we notice people who aren't
> > active in a timely manner, and distributing the load a bit more fairly.
> >
> > I propose we do this, and for concreteness propose the following rotation:
> >
> > - Feb 14th Ian Jackson
> > Feb 15th - Mar 31st Steve Langasek
> > Apr 1st - May 31st Bdale Garbee
> > Jun 1st - Jul 31st Anthony Towns
> > Aug 1st - Sep 30th Raul Miller
> > Oct 1st - Nov 30th Andreas Barth
> > Dec 1st - Jan 31st Ian Jackson
> That could work, though it's odd that Steve gets a shorter time
> in the chair than others.
Two month terms offset by a month give 7 people a go at being chair
at some point each year. It also lets us start sooner rather than later.
> Also, the handoffs are going to be interesting -- then again, the
> whole "rotating chair" thing is going to be interesting.
I don't see how they should be much of a big deal; the chair's mostly
just first among equals.
> > (2) Requiring an implementation of proposals
> > The md5sum "decision" is still languishing after a year and a half, and
> ...
> > So I propose we establish a rule that we won't make decisions on issues
> > that aren't ready for an immediate NMU when we make that decision.
> I don't know that we need to make a rule about this so much as
> advertise a guideline.
I was thinking along the lines of "rules of order", which isn't much
different from "advertising a guideline". The difference is if we set it
up as a rule, people can be confident we'll adhere to it, whereas if we
call it a guideline we might end up spending time wondering if we should
adhere to it on each issue.
> > (3) Advisory opinions from the chair
> ...
> > So I propose we establish that our procedure in addressing issues is
> > for the chair to quickly issue an initial opinion; and to only vote on
> > issues when an official ruling is needed (eg, to overrule a maintainer)
> > or when members of the tech ctte disagree.
> I'm not sure about this.
> If we need someone to shoot from the hip, the package maintainer
> seems just as good as anyone.
Depends: on "how should this work?" the maintainer's a good person to
make the call, but for "should the maintainer think about this again" or
"is the maintainer likely to get overruled" or "does this fit in with
broader Debian technical policy" the tech ctte chair's in a better position
to make the call.
It's not so much about "shooting from the hip" and giving a quick
careless decision, but giving an informal first-pass opinion -- "back
of the envelope" would be more the analogy imo; "shooting" just sounds
so final, which this wouldn't be.
> Usually, that means that there's something seriously wrong -- some
> critical piece of information isn't known, or some compatibility
> issue means that more than one answer is a good answer and that
> all of the good answers are bad answers...
That's the case for any tradeoff, though.
> But let's say we implemented this: what would do you think would
> be different as a result?
For #316883 / #342455 (devmapper), this happened:
* 2005-07-04: bug filed
* 2005-12-07: bug referred to tech ctte
* 2005-12-13: iwj replies querying more information; suggests ruling
* 2005-12-13: Guy disagrees with "castigation" portion of iwj's suggestion
* 2005-12-14: Bastian replies, discussion ensues
* 2005-12-24: discussion more or less ends
* 2006-01-03: iwj posts that devmapper perms should be different, but it's
not clear how
* 2006-02-02: rleigh asks if there's any resolution yet
* 2006-02-02: raul points to Bastian indicating he has an idea how to
fix it but hasn't implemented that yet
So I'd imagine two changes to this from the rules of order above. First,
I'd see the chair issuing an actual statement sometime between the
14th and 24th of December; the issues were pretty clear at that point,
and indeed iwj came pretty close to doing just that in his very first
mail. But as it stands, two months after referring the topic to the ctte,
rleigh still couldn't tell if there was any resolution. So I think by mid
to late December he should've been able to cite a first pass statement
by Ian to the effect of "devmapper should setup inodes with permissions
0600, and ownership as root.disk", possibly with a rider that that's
the chair's opinion not a final decision or whatever, but without any
devil's advocacy or further questions having already been dealt with.
Second change is that I don't think the tech ctte should consider
unimplemented proposals; so while Bastian's ideas might be great,
our choice of resolution is "leave it as it is" or "implement rleigh's
patches"; obviously once Bastian's idea is implemented, it could replace
either outcome, but until then we have to make a choice between things
we can do now. That's from issue (2).
> If your primary concern is inactivity, how about something more
> aimed at inactivity: Allow the chairman to propose a solution
> in some clear and formal manner, and if no one comments on
> it for a week then it becomes the defacto solution for that issue
> (this might require a GR to become valid for the project as
> a whole).
If it's only the de facto solution, then that's the intention of the
above, and doesn't require a GR.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature