On Fri, Dec 19, 2008 at 09:10:25PM +0100, Robert Millan wrote:
> > ,----[ The social contract is a goal, not a binding contract ]
> > | This amends the proposal above, and replaces the text of the proposal
> > | with: The developers, via a general resolution, determine that the
> > | social contract is an aspirational document: while we aim to achieve as
> > | much of it as feasible at all times, we don't expect to get it
> > | completely right for some time yet. This includes DFSG-freeness of all
> > | firmware
> > `----
> > ,----[ The social contract is a non-binding advisory document ]
> > | This amends the proposal above, and replaces the text of the proposal
> > | with: The developers, via a general resolution, determine that the
> > | social contract is a statement of principle only, and has no particular
> > | force on the day to day operations of Debian, except in so far as it
> > | influences individual contributors' actions.
> > `----
> How does this differ from the previous one in practice?
The main difference is in direction -- the former indicates that current
issues of non-compliance are bugs, that we promise to incrementally fix,
but aren't able to immediately.
The latter indicates the social contract is more of a "vision" or "mission
statement" -- something we might individually look to for guidance when
making decisions, but not something that's of practical influence.
So what's a practical difference? If you file a (valid) bug about some
package not-complying with the social contract (but somehow causing
no other ill-effects that would also justify the bug report), in the
former case the maintainer might reasonably defer it to post-lenny or
post-squeeze (perhaps with an -ignore tag in cooperation with the RMs,
or perhaps just by leaving a note in the bug log), while in the latter
the maintainer might reasonably close it outright, if that's what they
thought was appropriate.
(In none of the other cases could valid bugs about non-compliance with the
social contract reasonably be significantly deferred /or/ closed, where
"reasonably" means "in line with the project's expectations". stable
releases are one reasonable milestone for "significantly deferred",
but not the only one, IMO)
Cheers,
aj