Re: first proposal for a new maintainer policy
On 21 Apr 1998, Manoj Srivastava wrote:
> Hi.
>
> Philip> Does that satisfy both sides ?
>
> This satisfies me. Indeed, this has been my position all the
> while, but evidently the joys of the fray and the intellectual
> stimulation offered by the flow of reason has been a feast for my
> soul, and, added to my evident inability to coherently and fluently
> put forth my opinions in a convincing fashion has led to much of the
> conglagration on these lists.
Manoj,
Thank you for putting this back on development. I would never have seen it
otherwise.
BTW, you didn't conflagrate all by yourself ;-)
> Phil> Now clearly, these are not the views that are actually held by
> Phil> either side, which seem to come out as something closer to:
> Phil> A: Policy should be adhered to, except where (in the
> Phil> maintainers opinion) it would be more appropriate to
> Phil> something else (on technical grounds)
> Phil> B: Policy should be correct and up to date, in which case
> Phil> there should be no reason to allow exceptions, because
> Phil> things that are justified exceptions should be included in
> Phil> policy.
>
> Phil> Is that fair ? < donning flame proof armor ;-) >
Sure!
>
> Close enough (I would be in favour of amending policy to be in
> line with correct behaviour too).
>
> Phil> These are not nearly as far apart as you guys are making out,
> Phil> and could be combined to say something like:
>
> Phil> Policy should be adhered to.
>
> Phil> In cases where the policy conflicts with what they consider to
> Phil> be best for their package, they can chose to ignore policy, as
> Phil> long as they also attempt to have policy changed by discussing
> Phil> it on debian-policy.
>
> Phil> If this discussion results in a change in policy, well and good.
>
> Phil> If the discussion concludes that they were wrong, they must
> Phil> fix the bug that they have introduced into their package by
> Phil> ignoring policy.
>
> Phil> While the discussion is under way on debian-devel, there is
> Phil> little point submitting bug reports pointing out the policy
> Phil> violation, unless that violation results in behaviour that
> Phil> could damage a user's system if they installed the package.
>
> Phil> In any case, if a maintainer insists on uploading buggy
> Phil> packages, against the consensus of the Debian developers,
> Phil> various sanctions, up to and including expulsion from the
> Phil> project are always available.
>
> Phil> Of course, if the policy included a:
>
> Phil> ``Policy may by ignored while the clause in question is under
> Phil> discussion''
> Phil> clause, then the policy could also a have a
> Phil> ``Policy MUST be obeyed at all times''
> Phil> clause, since the exclusion would be in the policy ;-)
>
> Phil> Does that satisfy both sides ?
Well, we are at least moving in the right direction ;-)
First, some things that I think haven't been said yet (if that is
possible).
The Policy Statement is a, now not so recent, attempt at writing down the
Debian Policy that, up until then, was known to the developers by "shared
knowledge". The Policy Statement was made necessary as a result of an
enlarged development community, in order to insure that the previously
"shared knowledge" would be available to all.
It should be understood that, as a written document which governs how we
do development, this Statement will be under constant modification. In
recognition of this fact, the Policy Group should provide a well defined
method for putting a proposal before the Policy Group that does not
involve becoming a member of the group.
And finally, there are two classes of "bug" in the Policy Statement, only
one of which was been under discusion. We have spoken reams about those
items in the Policy Statement that are "broken", while ignoring the other
sort of problem: the one where policy doesn't say anything about the
issue.
With the above in mind, I would like to see the first sentance:
Policy should be adhered to.
expanded into a more descriptive and somewhat less restrictive statement,
like:
The Policy Statement contained herein defines the details of a properly
constructed Debian package. When it becomes necessary for a particular
package to behave counter to policy, the package maintainer should suggest
that the Policy Statement be modified to reflect the special needs of the
package.
I might also add:
When the Policy Statement does not say anything, or is unclear about a
particular issue, maintainers may ask the Policy Group for clarification.
This is actually probably going to be shared between the Policy Group and
the "Technical Committee", which is why I didn't include it outright.
In addition, I would like to see policy items identified with some
severity levels. Something like:
critical Violations of these policies will result in packages that
either don't work, or cause another package to fail.
cosmetic Violations of these policies create clutter or confusion
organizational No description comes to mind, but a good example is the
Single Maintainer rule for a package.
Those items that fall into the last two catagories should always provide a
set of guidlines (I mean principles) for deciding how to deal with
variances not explicitly declared.
The only problem I have with this catagorization is that it doesn't seem
to have a place for the "stripped binaries" rule. I guess it falls under
the area of "clutter" and should thus be "cosmetic", but the word inplies
too little concern...maybe a catagory between cosmetic and critical?
>
> --
> "Government is not reason; it is not eloquence; it is force! It is a
> dangerous servant and a terrible master." George Washington
Which urges caution when either using or being used...
Later,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: