Re: Nitpicking: you are doing it wrong
-----BEGIN PGP SIGNED MESSAGE-----
On 08.07.2011 15:56, Wolodja Wentland wrote:
>>> 1. You're using debhelper compat 7 and also only debhelper >=
>>> 7.0.50~ as Build-Depends. Please bump that to 8
>> Seriously? Is the sponsor suggesting that one should be
>> build-depending on a newer version, even though one does not use any
>> features of the newer one?
>> Also, the sponsor failed to explain that normally upgrading
>> debhelper compat is not a matter of bumping a number here and there.
> I can understand how this applies to older packages that have been created in
> the past and just don't use some of the new functionality, but I guess that
> the points are valid for completely new packages.
> I had the impression that it is desirable to create those in such a way
> that they use the latest compat, debhelper features and soon-to-be policy
> additions such as DEP5.
Jakub, I'm with Wolodja on this regard. While I totally agree with your
argumentation from a technical perspective, and I admit there are few
(no, even) reasons to /insist/ on such things, there are still good
reasons to suggest more state-of-the-art alternatives nonetheless.
Its about the wording, granted this. Maybe the reviewer should be
careful to say something like "Consider upgrading ..." or "There is a
newer compat level which is the currently recommended mode of operation"
but not literally "Upgrade to compat 8, yours is wrong"
This is because I still think its wrong to introduce _new_ packages with
older compatibility levels or older, but still policy compliant
practices. This is why I regularly point this out when I encounter such
packages and my sponsors did the very same with my packages.
We have a lot of older legacy stuff in Debian which would not pass any
RFS as of today, but this does not necessarily mean we should have this
level for new packages as well. This is why I don't consider a bit of
nitpicking wrong for new packages.
> Creating a package for the first time is a time consuming process, but
> should one not target the current state of the art?
with kind regards,
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----