Wouter Verhelst <wou...@grep.be> writes: > On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote: >> Adam Borowski <kilob...@angband.pl> writes: >> > Idea: perhaps we could make no unrestricted (maintainer, team, or QA) >> > upload >> > for 10 years a RC bug on its own? That threshold could then be gradually >> > reduced to eg. 5 years, as worst offenders get fixed. >> >> One could deprecate old Standards-Version and require a version not that >> was not superceded for more than five years. > > That's not what Standards-Version means. > > You don't get to say "I know my package does not comply with current > Policy, but the Standards-Version claims an old version of Policy so > that's fine". You must always be compliant with current policy (in > unstable), and if policy changes in ways that apply to your package, you > need to update it. > > One of my packages, logtool, hasn't seen an upstream change since the > early naughties, and as a result there are 7 years between logtool > 1.2.8-8 and logtool 1.2.8-9. > > That however didn't mean it wasn't maintained, just that it didn't need > any update in 7 years. > > The only reason for Standards-Version to exist is so that when you or > whoever comes after you look at things a few days/weeks/months/years > down the line, you know what has changed in Policy since it was last > touched and can use upgrading-checklist.txt
In my understanding the Standards-Version documents up to which policy version a package was checked for compliance. One could expect from maintainers that they check their packages for compliance regularly and that they document that. For a package that had no documented check for seven years it is OK to file an RC bug in order to clarify the compliance. Cheers Ole
