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
signature.asc
Description: PGP signature
