Re: releasing sarge
On Tue, Jul 06, 2004 at 02:16:50AM +1000, Anthony Towns wrote:
> Uh, can we have something more descriptive than just "the current
> release policy",
That's no problem, we could quote the specific document.
> and avoid dictating mechanism ("sarge-ignore") rather than just policy?
Well, it's impossible to be non-specific on this issue. The GR is
specifically keyed to sarge, and from the discussion leading up to the
vote, the intent of the GR is specifically keyed to DFSG interpretation
issues.
Could you be more precise about what it is you're looking for?
It's probably fine to say something like "[these] may be released as a
part of sarge".
> Also, some issues that would have been ignored before
> GR 2004-003 might not have been related to these concerns, and may not
> need to be ignored now.
>
> Points to consider:
>
> * what stuff must and needn't comply with the DFSG, according to
> the reverted social contract ("Debian will be 100% free
> software") -- docs, firmware, data files for games, rfcs, ...?
Here, there is some room for non-specific language.
Reading between the lines, I believe that complied C code designed to
run within the linux (or analogous) api, and interpreted code which
corresponds to some well recognized programming language must comply
with the DFSG. This is one constraint.
On the other side of things, only packages which were already release
candidates should be considered to be release candidates despite DFSG
issues.
Between those boundaries, it's ambiguous. And, I feel, deliberately
so.
Looking at the inception of the DFSG, I feel that issues which could
make it illegal to port software, or to fix critical bugs, should be
thought of as significant, and other issues should be thought of as
insignificant when resolving these ambiguities.
> * what stuff must and needn't comply with the DFSG when the SC
> is re-amended after sarge is release -- woody updates? sarge
> updates? stuff in the new testing? new uploads?
This was not specifically addressed by the GR. Looking at historical
practice, I think we can expect archives to remain available as long
as they are legal.
Updates... are a mixed bag.
Personally, I think that as long as updates to packages where there are
DFSG issues represent bug fixes (as opposed to rewrites, or similar
sorts of changes), that it's ok to release updates for such packages
as a part of sarge (including sarge-upates).
However, if they're tagged for some more recent release (testing,
unstable, sid, whatever), I think we need to take worse steps.
At that point, these should be critical bugs, and if the maintainer
is unwilling or unable to correct the dfsg issues that resulted
in those critical bugs being filed, the packages should be removed
from those releases.
> Note that there isn't really a "current release policy" on this issue --
> the policy before the original GR was clear, the policy since then has
> been ambiguous at best, and more closely approximated non-existant.
By current release policy, I meant the release critical policy which was
present at the url I mis-quoted. By the way, here's the corrected url:
http://people.debian.org/~ajt/sarge_rc_policy.txt
I'll try deriving a draft based on these ideas after I've had a bit
longer to reflect on these issues.
Thanks,
--
Raul
Reply to: