[QGIS-Developer] Explicit policy re bug fixing responsibilities after new features

[Nyall Dawson]

On Wed, 11 Mar 2020 at 13:30, Larry Shaffer <larrys at dakotacarto.com> wrote:

> Need some clarification on some particulars related to versioning and releases...
>
> Do you mean minor instead of major releases? You speak of reverting a feature prior to a *major* release, but features are introduced on master prior to every 4-month (minor or major) release, as indicated by your footnote for 3.14.

Yep, sorry. I meant 3.14 as opposed to 4.0

> "This extends from when the feature is merged into a development branch until its public QGIS release containing the feature."

Sounds much nicer :)

> Also ...
>
>> - After this major release, the developer is still expected to monitor
>> the bug tracker for issues relating to their work and implement
>> reasonable fixes at their own expense.
>> "
>
>
> Like... forever? What about the *value* of their contribution to the project itself? Something highly variable and relative, even for core features. And what about later, when the feature is stable, but needs refactored to meet other changes in the codebase? Does that then constitute a 'bug'?
>
> Maybe instead:
>
> "After the first public QGIS release containing the feature and until the next public release (or whatever interval is agreed upon), the developer is still expected to monitor the bug tracker for issues relating to their work and implement reasonable fixes at their own expense."
>
> I'd be hard pressed to convince any funding backers that they need to pay me to develop a feature and financially support it in perpetuity, especially if the feature also benefits the project/app and its users. However, it seems reasonable to say to a customer "and you also need to support the fixing of this feature's bugs found by the public until the following public release."

That sounds ok to me.

> I'm all for accountability in code maintenance, but there has to be a limit. Otherwise, contributions may become viewed as indentured servitude.

Ha. I'm sure the handful of current regular maintainers already feel
like we're slaves to all this abandoned code that other people are
pushing into master... And to be blunt, I'd rather these other
contributors/sponsors feel this pressure than us!

Nyall