Re: RFC: General resolution: Clarify the status of the social contract

[Felipe Sateler <fsateler@gmail.com>]

Manoj Srivastava wrote:

> I like the idea of clarifying what the principles of the project
> actually are, since, as aj said, all the decisions about lenny would
> fall out from the position the project take about the foundation
> documents. While I have always thought that "foundation" implied  the
> proposal below, apparently this is not a universally held view.
> 
> I think we will keep coming back to this biennial spate of
> disagreement we have, as we determine whether or not we can release
> with firmware blobs or what have you. This also would help developers,
> the ftp-masters, and the release team with a clear cut expression of
> the projects goals and clarifies how the project has decided to view
> the social contract.

I think that your set of proposals is only part of this particular issue. Part
of the issue is also how does the Social Contract apply to stable v
testing/unstable. Does the SC apply more strictly to stable? If yes, this
should be documented in the constitution or the SC itself. If not, then the
whole problem that started this is moot.
IOW, are DFSG-freeness "allowed" as bugs in testing/unstable but not in stable,
or are all suites equal in that if one of them can contain non-free bits then
it is up to the release team to consider such bugs as not delayers of the
release.

Something along the lines of:

,----[ The Social contract applies more strictly to stable releases ]
| The developers, via a general resolution, determine that the social
| contract should stop us from including anything that doesn't comply
| with the DFSG in main AND violations of the DFSG present in 
| the testing suite prevent the release of the next stable version.
`----

,----[ The social contract applies equally to all suites, violations
|      are considered bugs ]
|  This amends the proposal above, and replaces the text of the proposal with:
|  The developers, via a general resolution, determine that the social
|  contract should stop us from including anything that doesn't comply with
|  the DFSG in main AND violations of the DFSG present in the testing or
|  unstable suites do not necessarily prevent the release of 
|  the next stable version, since they were already present in Debian.
`----

,----[ The social contract applies equally to all suites, violations
|      are considered unacceptable ]
|  This amends the proposal above, and replaces the text of the proposal with:
|  The developers, via a general resolution, determine that the social
|  contract must stop us from including anything that doesn't comply with the
|  DFSG in main AND violations of the DFSG found in any suite are cause
|  for removal of the offending code inmediately.  
`----

If option 1 wins, then the lenny release gets delayed, and a new GR making a
formal amendment to clarify this in the SC should be done. If option 2 wins,
there should be a GR defining the process for determining wether a bug delays
or not the release (release team, GR, whatever). If option 3 wins, Debian
(including old releases) would become uninstallable for an unknown timeframe
until all DFSG violations are solved.

I do realize that this options are very related to your proposed GR, but I don't
really know how to solve that. Perhaps a wording that didn't shamelessly copy
your GR would help.

-- 
  Felipe Sateler