[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.



Reply to: