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
Attachment:
signature.asc
Description: Digital signature