Re: Constitutional issues in the wake of Lenny
Matthew Johnson wrote:
> 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.
I think the reason there were no comments is just because you tried to
cover the whole field, I would rather take one point at a time.
>> 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?
This is the difference between a goal and pragmatism AFAICS. It's not
because we have a position statement that *temporary* contradicts a
foundation document, that we want to amend the foundation document.
> 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.
I guess that would mean we should rethink all the foundation documents
as many items are currently already contradicted in practice...
>> - 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.
I don't see what this power to refuse would by us other than getting a
similar situation we had with the previous Secretary? I would rather
give the Secretary the power to delay a ballot for a limited amount of
time to actively try to clarify the ambiguity.
>> Release team vs DFSG issues
This is a very unfortunate way of looking at things IMHO.
>> 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.
If a known DFSG issue is in sid, that means there is no problem with
distributing it (or the FTP Team is not acting). By the way if the
Release Team would ignore DFSG issues, one would not find a Release Team
action that shows this fact. Tagging them <release>-ignore, is not
ignoring the bugs, but telling our developers that we don't think the
issue should delay the release. This tagging is of course only done when
it's clear that there is being worked on the issue, but that it's very
unlikely that it would be finished before the release.
Note that tagging bugs <release>-ignore does not at all mean they cannot
be fixed before the release. On the contrary, it means that fixes for
them are still accepted, but when the fixes are not in time for the
release, we're not going to wait for them.
> WRT the other issues, I'm happy with the seconding and supermajority
> options as they are, so won't be proposing we change them.
So is Dato leading the discussion for these other options?
Cheers
Luk
Reply to: