Jeroen van Wolffelaar <jeroen@wolffelaar.nl> wrote: > The ballot is now quite full, once it is time for seconds (not yet, let's > first discuss), maybe some options will fail to get five seconds, so they are > dropped. If all get enough seconds, well, this is what the voting system is > designed to handle: a very broad spectrum of opinions, and still a good method > to determine the best option for everyone. Given that we have two GR proposal out, with seconds, it's perhaps not too early to second, or rather propose, some parts. However, I think we should not make this decision in a hurry. From a technical point of view, it's about whether sarge will be released within a couple of weeks, or a many months, so delaying the vote for a couple of days is not a problem at all. On the other hand, this discussion is about our basic principles, we should really take the time we need. > The actual text of the current draft: > > =================================================================== > > This draft lists 6 options, ranging from completely going back to the previous > version, to keeping the current one and applying it to Sarge, with some > gradational-option in between: > > A: The recent Social Contract change is reverted > B: The Social Contract is changed to apply to software+documentation only I won't propose or second any of these. We will probably have to discuss whether some kind of data should be exempt from specific requirements that we pose on free software, but this is a different thing. > C: A clause is added to the Social Contract stating it will be effective > starting just after Sarge is released I think it is kind of ugly to write such a clause into the SC - it will need another GR to be removed once sarge is history, or it will be in it although it has no meaning any more. > D: Social Contract is left alone, but a GR is passed stating Sarge can be > released with GFDL docs and binary firmware I haven't followed the discussion w.r.t. closely, thus I don't know whether distributing it is a question of the Social Contract, or rather of our right to distribute it at all. As for GFDL stuff, I would support such a GR (see below). > Option C: > [I don't want that, but the rationale also applies to the following option] > > Rationale: > - Woody is also DFSG-buggy as above, delaying Sarge will also mean that our > current stable system violates the DFSG like we want eventually to prevent. > - Delaying Sarge will cause more users to think about a switch to other > distributions that will not delay a release for a very long time > merely because some problem that exists for many many years was just > recently decided to be release-critical, even though the current stand of > affairs is that there is a long time to go to fix it. "The problems associated with the GFDL [and firmware in the kernel] have been long known, and we have announced that we will ignore this for sarge, and release it soon, nevertheless. Being guided by the needs of our users also means to be reliable. If we decide, shortly before the release, that these problems are release-critical, many of our users will be dissapointed and feel fooled by us." > - It is very unproductive w.r.t. the recent talks with the FSF to get to an > agreement about the GFDL if Debian would mid-conversation drop GFDL from > main. It probably nullifies any chance to have a fruitfull discussion with > the FSF. Yes. > Option D: > > | It is decided to release Sarge when it's ready, even though it might still > | contain DFSG-related bugs of the classes (and only of the classes): > | > | - It contains GFDL documents > | - It contains binary firmware > | > | But DFSG-related bugs like: > | > | - Package is under a non-free license (excempting GFDL) ^^^^^^^^^^ ist this word correct? > | - Package has no license > | - Package cannot be distributed > | > | are still considered release-critical > | > | This resolution has no effect on releases after Sarge "This exemption will also hold for point releases of sarge, but not for any major release after sarge. Point releases will only fix security-related bugs and some other grave functionality bugs, as has been the practice previously" > Rationale: as Option C, and in addition: > - The Social Contract will not changed by this option, which would be quite > inconsequent, but rather it is clarified that implementing the new version > of the Social Contract for the upcoming release is not an currently > achievable goal, and that a delay in implementing is only a natural. > > - Only the wording of the SC has changed, the meaning has not. It was always > meant to say what it says now, and release management has decided to ignore > particular classes of violations for the sake of releasing Sarge. It was > agreed by consensus that this was ignored before, so it should be ignored > for Sarge also at this moment. This is also my opinion. However, the fact that: > Con: > - Anthony Towns has stated that he wishes to not violate the Social Contract > releasing Sarge, even if a GR like this one is passed allowing him to do so. is quite pressing - I do not want to change the Release Manager. But I think if such a GR is passed with a majority that would be sufficient to change the Social Contract, it can be viewed as if it was a change to it, but with just a temporary effect, and an "automated removal" once sarge is history. Regards, Frank -- Frank Küster, Biozentrum der Univ. Basel Abt. Biophysikalische Chemie
Attachment:
pgpP_VWhvRmUH.pgp
Description: PGP signature