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