On Wed, Jul 14, 2004 at 12:43:13PM +0100, Andrew Suffield wrote:
> On Wed, Jul 14, 2004 at 02:44:02AM -0500, Chris Cheney wrote:
> > On Tue, Jul 13, 2004 at 09:41:04PM +0100, James Troup wrote:
> > > Hi,
> > >
> > > If anyone thinks this GR will actually achieve anything positive,
> > > they're mistaken.
> >
> > A GR to make the various delegated developers communicate would be better
> > but that probably wouldn't work either...
>
> Correct, a resolution that says "Foo must perform action A, instead of
> not performing action A" is explicitly a no-op under the constitution,
> and is also obviously silly.
Correct. The appropriate GR is "Foo shall be removed for failure to perform
the duties of $position", with the rationale citing "failure to perform
action A, a duty of $position".
Or, in this case, more likely a rationale citing a pattern of extended and
repeated incidents of failure to perform the duties of the position or
provide adequite feedback to the project at large (either directly or via
the DPL) about why the duty cannot be performed in a reasonable fashion at
the current time.
> Frankly, GRs are almost useless. The only particularly good reason for
> using them is when the constitution says that we have no other choice
> (like editing the blasted foundation documents).
Or the above. Not that I think it is the best answer, or even the right
one, or a particularly useful one, in likelyhood. But if the pattern of the
ftp-masters continues as it has been ever since I joined the project, I
won't be suprised to see someone make the GR proposal at some point here.
Please note that I'm not trying to be insulting here; it is simply my
personal experience that the ftpmasters as a whole have never, in any
situation I have been a party to, been particularly communicative, and
that Mr. Troup in particular, in *multiple* of his roles, appears to be
particularly prone to failing to communicate in what *I* consider to be
a timely or appropriate fashion for the execution of the duties of those
positions. Others have their own experiences and perceptions; perhaps they
find it perfectly acceptable. If someone proposes a GR about it, then
we'll measure the vote; if not, little meaningful can be said about the
statistics, I think.
On a sidenote, I might well vote for a GR that directs the ftpmasters to
add the amd64 architecture to sid with all achieveable speed as a technical
decision overridding the (apparently de-facto) decision of the ftpmasters,
under the auspice of section 4.1.3 of the constitution; I think it is
neither adviseable nor reasonable to forcibly declare that it must be in
sarge, though I do think that realistically, if we as a project want to be
in any way able toc laim to have our users' interests at heart, we should
plan for and expect that amd64 will be part of Sarge in a point release,
even if it hasn't managed to propagate completely to testing by the main
release date.
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU/kNetBSD(i386) porter : :' :
`. `'
http://nienna.lightbearer.com/ `-
Attachment:
pgp46XbZ01twE.pgp
Description: PGP signature