Re: Clarification of Policy and Packaging manuals requested
-----BEGIN PGP SIGNED MESSAGE-----
> Zed> I think that mindset is not in the best interests of the Debian
> Zed> project.
>
> I think I disagree. Letting developers who can't write shell
> scripts can in no way be in the interests of the project, one of
> whose goals is *excellence*.
Let me then put it in a different light. I can write shell scripts.
Slowly. To be honest, I haven't had anywhere near enough practice. If I
were faced with some of the problems discussed in devel, I would
*eventually* have come up with the answers you posted. I'm working on a
couple of them now, trying to get IRAF into a sufficiently
policy-compliant state to get it into contrib. If I were highly
proficient, it might not matter too much to me, except that even someone
proficient can overlook things (I'll be filing a bug report against
dotfile-procmail shortly for not deleting out the byte-compiled file on a
purge -- a small scripting oversight, I'm sure). As it is, however,
I'll take any tool I can get to speed things up a bit and reduce the
chance of my screwing up something subtle. Despite this, I like to think
that it is less than hubris on my part to make the claim that I have
something to offer the project. (Side note -- I finally made most of the
transition to hamm, breaking a few of my pthreads-tied applications, but I
found either workable substitutes for them or ways to get around not
having them, so I'll be at least working on the same software ground as
the rest of you, now.)
And from a completely tactical point of view, I think you'll get
higher quality overall when people are using tools that the Debian project
as a whole can monitor and make certain function properly than when
they're writing shell scripts that could contain a number of problems that
could remain hidden until someone observant did something unusual to them.
> The community at large does not get to put random bits of
> software on my production machine.
Point well taken.
> I do not wish to promote quantity at the expense of
> quality. If it is in Debian, it is a high quality product. I never
> want that diluted.
Neither do I. But the promotion of quantity is not axiomatically at
the expense of quality, and it's also important not to _hinder_ quantity
when quality won't be affected. Beyond this, it's important to think
about whether restricting a tool is going to increase or decrease the
quality of the project in general. I'm not advocating random deviations
from Policy (I wouldn't be spending so much time writing this message in
this forum if I were) -- Policy exists in part to create the structure in
which a quality system can exist. However, I don't think anyone believes
that Policy will always be perfect.
In this particular case, I believe that quality -- and quantity --
will be benefitted by making this tool available outside of the sole realm
of configuration files. Whether that should be done by opening conffiles
to general use or by creating a parallel tool... well, we can argue about
that next :)
=============================================================================
Zed Pobre <zcp@po.cwru.edu> | PGP key on servers, fingerprint on finger
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: 5.0
Charset: noconv
iQEVAwUBNPI+t9wPDK/EqFJbAQGskAgAo8rRx/9nPiMCkDokmRs4qy5TZXFI4LsV
mM6yR9m3ZVH+305mCY3FojIXhi2h00zr+TZ1sBghyFH0rmM5VP7HiQTzOwG5lIAR
8mjY7JFI4jYCoEmKBbIbx0eLAaTUZtfo7VaOoiKnC9LuLVpuPMzkjm/gQsR3XEbO
NgEP+j7ACB/SwkEVFVkN4hIpRTOQDTePx7M9tdbg7bDer4RRn/oQTEiysucrnj5R
Y658v9Ma+Q0JOf70zw7Jbu4Vn+5iKFYo4OxJOQ8vv68o3Xn/ssHmuYGcu0BZV/Uo
AL48je+SlgRReEddWEZWJD/wSEJstiEPy5x/FeqMVun8l1zJhRYBWw==
=FkRG
-----END PGP SIGNATURE-----
Reply to: