Bug#1142295: debian-policy: Policy major digit should match the Debian release version

--=-=-=
Content-Type: text/plain

Sean Whitton <[email protected]> writes:

>> Personally, I've never found the upgrade checklist relevant for
>> per-package upgrades.  I find the checklist useful to understand what
>> changed between policy releases, but more as a curiosity to understand
>> general preferences over time.
>>
>> This is because 1) the upgrade checklist often lacks concrete actionable
>> recommendations, or 2) for those things which ARE concrete and
>> actionable, lintian and the Salsa CI/CD pipeline are a more
>> cost-effective way for me to discover what I need to do.
>>
>> Granted, I do run the risk of missing something really important that
>> the checklist say I should do.
>
> I don't think this is an advisable way to go about updating the
> Standards-Version field.  I think I'd prefer you just didn't update it
> at all, than update it without being sure you captured everything.

I suppose one can never be certain of not making mistakes even if one
carefully reads the checklist for every package upload.

> Patches to the upgrading checklist to improve its usefulness to you
> would be very welcome, btw.  I write almost all the entries, but usually
> with the full context of the issue in my head at the time, so I wouldn't
> be surprised to learn that many of them assume too much to be useful.

My workflow is to read the checklist to understand what is going on, and
then condense that into "what changes do I really have to make" and
after 10+ uploads of Go packages making those changes, I feel
comfortable knowing how a "proper" Go package complying with 4.7.4
should look like.  Then I stop looking at the checklist and merely
continue to adapt each new packages to look like they had been a freshly
created Go team packages.

I feel this leads to better use of my time than revisiting the checklist
for every upload, where I'd certainly be MORE likely to mis something
since some packages haven't been updated in 5+ years.  That is compared
to making the packaging consistent with how it would look if it was
packaged today.

I think this is acceptable for low-complexity packages like golang-*
which could all just be templated anyway.

But I rest my case about making Standards-Version optional now.

/Simon

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmpieVMUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4fWRBQkOa+rdAAoJENc89jjFPAa+hWIA
/1lQvrJeGlQq50lP6tm99D1zDy7J1tQ3ha4x0Jx7rkFTAP9hpUKuTvm6m1fXyiZV
YZlu2+Id/Dq3CIAZvNF+XEr2BLgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCaeCW1wUJDmqLVgCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+s7AA+gIIHpBApDpcDj1sKhzDngmpvwQf0VkHme6s+EG7qSgpAQDe
/XMrU0c0Pa3ji85cMqZhvzJOFI/soe662lzL0QY3Bbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJp4JbXBQkOaottAAoJENc89jjF
PAa+RNUA/2faQO/nFT06E+MlhlQdo/0chlQXC5TZMPTVvVBFwoLOAP9xLJK0ow5E
jTzYJB4K810AL/Iv6PEOAEgA4cPTHVlbCQAKCRBRcisI/kdFopjVAQDpOGkqbOax
j5WstiDQOQJ6FaSywofUQHOqM8TShUE6swEAidZXB/A+IG1nVRk7TMliylHY0D2J
D5bSGHUfLstAFQs=
=K+f7
-----END PGP SIGNATURE-----
--=-=-=--