[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

release policy

[Personally, I've been pretty busy the last few weeks and expect to
remain busy for a few more (two weekends ago, it was work, but since
then it's been unexpected family obligations).  However, I've a free
couple hours at the moment...]

Currently, we've been asked to makes some decisions about release policy.

On the flip side, the constitution says "The Technical Committee does
not engage in design of new proposals and policies", and I'm wondering if
Anthony is expecting us to do so instead of deciding on specific issues.

I think we'd have no problem ratifying a problem, or deciding on specific
issues, so here's the specific questions and statements:

Jun 9:
   Please do whatever you think's best for the project.

Jul 6:
   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, ...?

        * 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?
Jul 16:
   Please read my previous email to the -ctte list and address the issues
   listed there.


We could ratify some current policy, which would in a sense freeze it,
but it's not clear that that's "best for the project".

I'm guessing you (AJ) are waiting for us to design some release policy,
while we're trying to figure out how what you've asked us to do makes
sense.  If we keep waiting for the other to act in this fashion, we'll
just be introducing delays.

If you want us to design policy, that's a non-starter.  If you want us
as individuals to participate in the design of some policy, that could
probably happen, but shouldn't happen on the ctte list.  If you want to
delegate specific questions to us (e.g. decide about specific packages
or about some specific policy), you can delegate that to us, but note
that we'd likely either be focussing on technical issues or trying to
figure out how to delegate the issues to whoever is active in that area
(if that turns out to be you, we'll probably be approving what you ask
unless there seem to be technical problems in which case we'll likely
either disapprove or sit on it depending on whether or not we achieve
any sort of consensus on the issue).

All my predictions about what the committee will do are guesswork.

The big from the constitution which indicates that we don't do detailed
design work is not.

Some further guidance on what decision or decisions, specifically, you've
asked us to decide on, would be appreciated.  In particular, should we
take the question marks in your "points to consider" as representing
the full set of questions you've asked?  In other words, have you asked:

Under the reverted social contract:
   Should docs comply with the DFSG?
   Should firmware comply with the DFSG?
   Should data files for games comply with the DFSG?
   Should rfcs comply with the DFSG?
   Should woody updates comply with the DFSG?
   Should sarge updates comply with the DFSG?
   Should stuff in the new testing comply with the DFSG?
   Should new uploads comply with the DFSG?

As an aside, my personal interpretation on these questions in light of
the most recent GR is:

Packages in the above categories which previously had been considered
release candidates for Sarge, or have been released in Woody, should
retain that status regardless of DFSG issues and should continue to
retain that status in updates, and in the Sarge release.  If they lose
that status for some other reason (we can't distribute them legally, or
some technical release critical bug), then they shouldn't be released
until that reason has been addressed.  For releases after the Sarge
release, whatever they happen to be named, .deb packages which fail to
comply with the DFSG should be considered a release critical bug.  Also,
"we can't legally distribute this" can be grounds for removing a package
from the archive if the issues are severe enough.

If this is the sort of decision you're asking us to make, please
indicate so.  If this is not the sort of decision you're asking us to
make, please be more specific about the nature of that decision.



Reply to: