--m8yuz6kcWj4yJ5vq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 26, 2005 at 09:52:06PM +0200, Roland Illig wrote:
> Quentin Garnier wrote:
> >On Fri, Oct 07, 2005 at 12:53:02PM +0000, Roland Illig wrote:
> >
> >>Module Name:	pkgsrc
> >>Committed By:	rillig
> >>Date:		Fri Oct  7 12:53:02 UTC 2005
> >>
> >>Modified Files:
> >>	pkgsrc/security/sudo: Makefile
> >>
> >>Log Message:
> >>Fixed a pkglint warning.
> >
> >
> >Shouldn't pkglint be fixed instead?
>=20
> I don't think so. I have added the warning with a specific purpose: To=20
> catch misspelled or superfluous instances where PKGREVISION is defined.

We've had "PKGREVISION=3D #empty" around for quite a while, and the code
where PKGREVISION is checked explicitely checks for emptiness.

> >(Note: this particular commit was annoying because besides fixing a
> >non-existent issue
>=20
> My change may not have fixed any bug per se. Nevertheless I felt a need=
=20
> for this change because creating new packages is often done like taking=
=20
> an existing Makefile and modifying it until it fits. That is, every=20
> current package is possibly used as an example how to create a working=20
> package. These examples (that is: every package) should not only work,=20
> but should also represent the way new packages are intended to look=20
> like. Specifically, I want the packages to "look good" and "feel good".=
=20

For your definition of "look good".

> Just remember that NetBSD is said to be of high code quality.

Yes, and PKGREVISION=3D #empty is bad because ... ?  It explicitely states
the variable is left empty, so there is no chance it is a typo or
something.

And I'd say people who look at the said code would rather replace "high"
with "better".  Just saying.

> > it broke consistency with the branch
>=20
> Maybe I haven't taken the "best time" to apply this patch. Had it been=20
> better applied shortly _before_ a branch instead of shortly _after_, to=
=20
> minimize the probability of having to pull it up?

You don't pull-up cosmetic changes, hence it's better to have them
happen right before the branch.

> >which means it's not as easy to pull-up securtity-related changes.
>=20
> >Sudo has bad history, it's not a reason to make things harder.)
>=20
> I don't understand this "bad history". :(

Sudo has a bad security track.  Therefore PKGREVISION bumps that get
pulled-up happen way more often than for other packages.  Gratuitious
commits gets in the way, that's all.

At the end of the day, when you're tired and you want a security fix to
hit the users as quickly as possible, it's slightly annoying.  I'm not
saying I'll fight over this, of course not, but fixing stuff that works
do very little good (except for the eyes, alright).  Ask Perry ;)

--=20
Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.

--m8yuz6kcWj4yJ5vq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQ1/kUNgoQloHrPnoAQIPmAf/Sk8+/FLl8+NrSO9PAzsxK2edxvr4G6iu
p/KBnVF9A48ljGpRyVhW39HH1x1elzUOazAEnq6UazNXRQJlbQ23YlLFEp8ifBQq
KVT2w+2Cd2d/hWcDQ9KZ/9y+AMXOvIdQPK5M9blxjwp+c969jKawd0geSipQ/NDi
2YzoUazZ0XNi7yNB1jU8PpvcMBumAPgGAxjsFhvR08ePq05eDkpSaJKBM42xT/Am
kyhJLopVUcwIodIrrJin1FPUVoEWOpKVBt+2eakdYNntU1x3aLN4vhqWvMHPSItj
ATZWkSjWy93AciwjzmKWmHR7TCQ+iV1BoUzoMhVuyhPCF5ymJlrA7Q==
=LVTi
-----END PGP SIGNATURE-----

--m8yuz6kcWj4yJ5vq--