Re: Should the policy documents better reflect real package maintenance practice?

[Kevin Fenzi]

On Thu, Nov 24, 2022 at 01:42:20PM -0800, Adam Williamson wrote:
>  
>  Thinking it over some more - I think Gordon's right that I hadn't
>  considered all the language - I think my personal opinion would be that
>  the policy should be adjusted to be less opinionated on this idea of
>  "introducing features", and concentrate more on "unexpected changes to
>  the user experience". There are a lot of cases where introducing
>  features is entirely benign, after all. If a CLI tool I use grows a
>  useful extra option while still supporting all the ones it had before
>  and behaving in the same way when using those, that just does not seem
>  like something to be concerned about. I'd happily send such an update
>  to stable.
>  
>  If the update *removes* some existing argument, or changes the
>  behaviour of one, that's much more significant.
>  
>  This is really kinda the rule about API/ABI changes, only for
>  applications, in a way. Adding new functions to a library doesn't
>  change the API, only removing or changing the behaviour of existing
>  ones. 
I agree. I think this is something we have in the past for gui things
called 'changes in the user experence'. But yeah, we could clarify this
better. 

FWIW I think some cases were grandfathered in when the policy was first
aadopted. firefox and kde for sure. I know I requested a exception for
calibre. 

The policy is also a bit unclear (or just wrong as written) saying
exceptions need to file for every update or can be just 'you have an
exception for this package/collection of packages unless something
changes'. 

kevin