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. Matt -- Matthew Johnson
Attachment:
signature.asc
Description: Digital signature