Re: trends.debian.net updated
Wouter Verhelst <wouter@grep.be> writes:
> On Sat, Apr 04, 2020 at 08:03:09PM +0200, Ole Streicher wrote:
>> Adam Borowski <kilobyte@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
Reply to: