On Mon, 20 Apr 1998, Christian Schwarz wrote:
>
> [I reduced the list of recipients.]
>
> On Sun, 19 Apr 1998, Dale Scheetz wrote:
>
> > On Sun, 19 Apr 1998, Christian Schwarz wrote:
> >
> > > It's up to you which guidelines you want to follow--but if you want to
> > > maintain packages for our distribution, you'll have to follow our
> > > guidelines! Our policy applies to all packages in the distribution. Any
Your use of the word guidelines here is confusing considering the position
you are taking here.
My understanding of a guideline is a "suggested direction" or an
"indication of the best method". I have never heard guidelines used as
"something that must be followed to the letter".
> > > package failing current policy in a severe way will be removed from the
> > > distribution.
> > >
> > Then you will need to remove libc6, as the loader is not stripped, as
> > dictated by policy. If I strip it, as policy demands, it will not work.
>
> I said `failing [...] in a severe way'.
I didn't think that I got any chance to make any decissions about the
"severity" of my violation. It is very clear in the policy statement that
this is a violation.
This statement only makes me more confused.
It is ok not to strip a binary (this you say isn't severe), but not ok for
two people to jointly maintain a package? Where exactly is this sliding
scale described in policy?
>
> > Policy statements that fail to provide an adequate exception mechanism are
> > totally broken.
> >
> > We have several "work arounds" for this policy, and the "not yet
> > authorized" package in question will not be the first that desires, or
> > requires, more than one maintainer.
> >
> > I have yet to hear a good technical reason for restricting package
> > maintainance to a single person. Yes, there are several accounting issues
> > that keep coming up, but those are for the individuals actually
> > implimenting a multi-maintainer package to resolve between them.
> >
> > Personally, I find this dictatorial attitude about Policy as potentially
> > more dangerous than no policy at all.
>
> Please read my message again more carefully. I only objected to the way
> you treat policy.
>
My objections are the same. I object to the way that you treat policy.
> The reason for our policy is not part of _this_ discussion--it is
But such reasons should be made clear in the documentation that demands
the behavior.
> discussed on debian-policy in another thread. The only thing that counts
> in this discussion is that it's *not* up to the maintainer to decide
> whether he/she wants to follow policy or not.
>
Well, spank me with a switch!
If I am being asked to check my brains at the door, then I will just need
to find another place to hang out. This attitude you are projecting is not
a cooperative one and fails to create the feeling of cooperation that is
absolutely necessary for this project.
> If you're intrested in discussing pros and cons of section 2.3.2, please
> join the discussion on debian-policy.
>
Even if I were so interested, I have no time for the things I must do,
much less something that is being dealt with in this fashion.
If you need a better excuse than this, just chalk it up to your "friendly"
attitude.
Aside from your attitude about dual maintainer packages, you expressed
resistance to there even being such a package split. Is this one of the
dictatorial powers you now have? I always thought it was up to the
developers whether a package is built or not.
Luck,
Dwarf
--
_-_-_-_-_- Author of "The Debian Linux User's Guide" _-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (850) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
