On Tue, Mar 30, 2004 at 08:32:37AM -0600, Manoj Srivastava wrote: > Policy does not document all existing practice. It only > incorporates a minimal ruleset that is required for systems > integration (usually selecting one branch from several equally viable > technical options). It is not a best practices document. > > Policy also should almost never (unless directed by the > tech-ctte, and perhaps the DPL) cause a change that would make a > significant chunk of packages instantly buggy; for such changes, we > implement a gradual transition plan, allowing for partial upgrades > (and perhaps using release goals as motivators). Part of the > rationale for this is common sense; a global change, in the past, has > taken time, and having either a large number of RC bugs, or ignoring > a large number of bugs that would otherwise be RC seems silly; and, > anyway, there are concerns that the policy group does not really have > the power to change policy drastically. This is the basis of the > policy shall not be used as a stick to beat developers with. > > Nor does it _always_ document only existing practices. What > that misquoted statement was a part of was a larger thesis that is > meant to suggest that policy is not the place for testing out design; > if a complicated technical proposal is to be made into policy, it > should be independently implemented, have all the kinks worked out, > and then have that working model be implemented as policy. Having to > change policy back and forth while a design is being worked out needs > be avoided. Okay. Maybe the above should be added to the Policy Manual as a preface. -- G. Branden Robinson | When dogma enters the brain, all Debian GNU/Linux | intellectual activity ceases. branden@debian.org | -- Robert Anton Wilson http://people.debian.org/~branden/ |
Attachment:
signature.asc
Description: Digital signature