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

Re: Constitutional issues in the wake of Lenny

On Mon Mar 02 00:23, Matthew Johnson wrote:
> The votes around the Lenny release revealed some disagreements around the
> constitution, DFSG, supermajority requirements and what people think is
> 'obvious'. What I would like to do is clarify some of these before they come up
> again. To avoid overloading -project I'd like to move the initial discussion
> somewhere else. If you are interested in developing the ballot options for
> this, please follow up on -vote. We'll move back to -project when there are
> more firm suggestions.

Hmm, so far the discussion has been rather less verbose than when the
issues were blocking Lenny. While not having arguments is good, I really
do think we need to make sure we don't have the arguments again for
squeeze. My previous email tried to cover the whole field of views, this
one is my personal view, which I want to run to a GR to make the
constitution and FDs explicit on the points which were ambiguous in the
discussions pre-lenny.
> Overriding vs Amending vs 'Position statement'
> When a GR has an option which contradicts one of the foundation documents, but
> doesn't explicitly amend it; does this count as amending it? If it does not,
> then how is this reconciled with the fact that we have just agreed to do
> something which would contravene our own foundation documents?

I personally believe that any vote which contradicts one of the FDs,
even if just a temporary or limited scope exception, implicitly modifies
that FD and therefore requires a supermajority. Such votes should be
included (probably via a hyperlink) in the FD itself.

>    - Ballots which are ambiguous about resolving the clash between them
>      and a FD should be rejected and not run.

I also believe that the secretary should have the power to refuse to run
a ballot option (by delaying the vote as appropriate) if he believes
that it contradicts a FD but the ballot option itself does not
explicitly claim to or otherwise resolve this problem.

> Release team vs DFSG issues
> DFSG applies to sid. If it's there and no-one has removed it, the RT can
> snapshot the archive at any point for the release. DFSG or other RC bugs; it's
> up to them whether to ignore them. This is possibly a subset of the above two
> items, however, I think it's important enough to warrant being explicitly
> specified.

The release team is appointed by the DPL who is elected. I think we
should trust them to do their job and hence empower them to make
whatever decision they like about whether a bug (of any severity) blocks
the release. Other developers can override this by GR as normal
(although, they should in general listen to people who disagree first
 and policy on the overrides should be set early in the release cycle).

I intend to propose the above three votes (I'll work out actual
wording), all of which will explicitly modify things.

WRT the other issues, I'm happy with the seconding and supermajority
options as they are, so won't be proposing we change them.

Matthew Johnson

Attachment: signature.asc
Description: Digital signature

Reply to: