Bas Wijnen <wij...@debian.org> writes: > On Tue, Dec 16, 2008 at 11:18:12AM -0800, Russ Allbery wrote:
>> Where? That states how you make an amendment. It doesn't say that the >> secretary can declare something that isn't an amendment to be an >> amendment so far as I can tell. > It says "according to the requirements for a new resolution", which > seems to allow things proposed as a new resolution to really be > amendments. I believe that you really think that, but I don't understand how you could get that from that text. How does saying that the procedure for making an amendment involves the same requirements as making a new resolution imply that new resolutions can be turned into amendments? > I admit it's not really clear, and can as well mean that an amendment is > something different which only has the same requirements. Until this thread, I would have thought that it was completely clear. I'm still not managing to see another reading than the one that to me is obvious. (Although I guess that's other people's reactions to my understanding of what the SC says, ironically.) >>> I agree that the wording of several options, including 1 and 5, is very >>> vague. I assumed that it was clear that ignoring a DFSG violation for a >>> release is in itself a violation of the DFSG. This view is appearantly >>> not shared by everyone. >> Surely you realize that this phrasing is highly controversial and >> confrontational, given that the release team doesn't believe that >> they're ignoring the DFSG? > Are you talking about my wording, or about the wording of the options? I was talking about your wording. >> I don't believe they are either. > Neither do I. The reason I asked was because you seemed to say that > they were, and that FD would allow them to continue doing that. I now > understand that you didn't mean that. I definitely wasn't saying that. I just checked all of my messages to this thread and I have never used the word "ignore" except in response to your messages citing things that you're saying, so I'm not sure how you could have gotten that idea, but I apologize for giving the impression. I think I understand where your wording came from now. It was an attempt to restate what you thought my position was? It's very different from my actual position, so I didn't recognize it at all. >> I really wish people would stop accusing other project members of >> ignoring the DFSG even if you disagree strongly with their >> interpretation of how the DFSG is applied. > > I think you are talking about me here. Among others, but yes. > I haven't actually seen anyone making this accusation. The only time it > was mentioned was when I asked you if this was what you meant. To be > clear, I immediately followed it with a statement saying that I didn't > actually think so myself. Okay, it appears to have all been a misunderstanding. I'm not sure how we managed to misunderstand each other to that degree, but I guess it happens. > I think I agree with this... However, it means that if anyone (delegate > or other DD) is violating a foundation document, only a 1:1 majority is > needed to allow it by not deciding to forbid it. Right, via a delegate override. > That does seem rather strange, since 3:1 would be required (IMO at > least) to explicitly decide that it is allowed. This is where I have a strong disagreement with Manoj and apparently with you. I don't think there's any justification in the constitution for requiring a developer statement about the project's sense of the meaning of the SC and the DFSG to have a 3:1 majority, or to make a developer override to enforce that sense of the meaning. Both the override and the statement about the meaning of the documents should require 1:1. 3:1 should only be required when the documents are explicitly superseded or changed, not just for making a project statement about their interpretation. (Just to be clear, in this parcticular case, I continue to believe that changing the text of the SC and/or DFSG is superior to issuing a project statement about their interpretation, since doing the former is going to be much more conclusive and long-lasting and will avoid, hopefully, doing this again for squeeze. But that doesn't change my analysis of what the proposal originally put forward was actually intended to do.) -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org