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

Wed Mar 11 09:17:33 PDT 2020

Hi Andreas, et al.,

On Wed, Mar 11, 2020 at 3:26 AM Andreas Neumann <a.neumann at carto.net> wrote:

> Hi,
>
> In general, I agree with Nyalls proposal. As a customer or user of QGIS
> who wants stability, this is a good thing.
>
> But like Larry, I think we should be careful and not ask a dev to be
> responsible for a new feature during his lifetime ;-) ( I know this is
> exaggerating ). Let's limit the responsibility until the release of the
> next LTR version. I think that would be a compromise that protects both the
> customer, the developer and QGIS.ORG.
>
> I think support relative to public release cadence, instead of specific
versions will make more sense to sponsors/customers. Otherwise, you end up
with the same issue when focusing on LTR as with specifying a major version
(e.g. substitute LTR for 4.0.0):

Larry Shaffer wrote:
> If you do mean major, then this could be quite some time and possibly
> unequal per author, e.g. one feature introduced in 3.0.0 needs supported
> until 4.0.0, while another in 3.14.0 has a much shorter support cycle to
> reach 4.0.0.

I think the focus here should be on stability over a given time span, not
any specific version. I suggest "from the point of merging through the
public release with the feature and until the next 1 or 2 public
release(s)."

The reasoning here is that if a feature causes instability beyond a 4-month
release cycle, then something is VERY wrong with it, or it is so
complicated no one can correctly solve it yet. Either way, action needs to
be taken, i.e. disabling or removing it. The curse of self-inflicted
instability should not be allowed to persist beyond a single release.

Conversely, if the feature is stable after a full 4-month release, with
patch fixes, than it can probably be viewed as a complete contribution, or
not enough users have actually used the feature yet (corner case, I think).

Even a 8-10 month support cycle (two public releases, regardless of
version) makes sense, given most bugs for stability should be worked out
within the first 4 months; although, it *might* take fixes or another
feature in other parts of the codebase to make a broken contribution work,
i.e. needs one more general release. The latter might be a better option
than removal of the broken contribution or disabling it.

And, as the treasurer, I think it is totally ok, if the general QGIS.ORG
> funds are also used for bug fixing of features paid by someone else. After
> all, the customer and developer did their contribution which benefited all
> other QGIS users. Now, all the other QGIS users can contribute to the
> maintenance, esp. if they don't pay for feature development.
>

I think the point here is that, regardless of funding source, incomplete
contributions, i.e. ones that cause issues/bugs after merging, and there is
not a concerted effort to fix by the author(s), should not rely upon other
devs or the project's bug-fixing funds to get its code (or QGIS) working
prior to public release.

People make mistakes and having such an awesome community to help solve
them is what makes this project a joy to work with and contribute to.
However, it must not be OK to even have the appearance of contributors
abusing that relationship. Stringent guidelines here help everyone involved.

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota

> As a consequence of this proposal, devs should raise the hours budgeted
> for a new feature and as a consequence the price for the customer.
>
> Greetings,
>
> Andreas
> Am 11.03.20 um 04:30 schrieb Larry Shaffer:
>
> Hi Nyall, et al.,
>
> On Tue, Mar 10, 2020 at 4:55 PM Nyall Dawson <nyall.dawson at gmail.com>
> wrote:
>
>> On Wed, 11 Mar 2020 at 03:31, Alessandro Pasotti <apasotti at gmail.com>
>> wrote:
>> >
>> > I've always felt it was an implicit agreement, but I totally agree
>> > that making it explicit is a good idea.
>>
>> Yep, it's been more or less "understood" practice for some time, but
>> I'd like it to be official so there's no room for misunderstand.
>>
>> > Where exactly would you suggest to add that kind of statements?
>>
>> I'd put it in a new section under
>> https://docs.qgis.org/testing/en/docs/developers_guide/  Maybe
>> something like "development policies"?
>>
>> We could word it something like:
>>
>> "While new feature submissions are always highly appreciated, every
>> feature added to QGIS comes with an associated maintenance burden for
>> the project. Accordingly, some policies exist to avoid placing this
>> burden on the existing QGIS development team:
>> - Following any new feature development, it is the original
>> developer's (or organisations) SOLE responsibility to proactively
>> monitor and implement bug fixes relating to the new feature (or
>> regressions to other parts of QGIS which have resulted from its
>> development). This extends up to the next major QGIS release following
>> the feature being merged*. It is NOT acceptable to use QGIS.org
>> sponsored bug fixing efforts to implement these fixes. Failure to
>> provide fixes to all reasonable bug reports raised for a
>> new feature may lead to that feature being reverted prior to release.
>>
>
> 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.
>
> If you do mean major, then this could be quite some time and possibly
> unequal per author, e.g. one feature introduced in 3.0.0 needs supported
> until 4.0.0, while another in 3.14.0 has a much shorter support cycle to
> reach 4.0.0.
>
> Regardless, I suggest scheduling the expected new feature support relative
> to the public release *cadence*, regardless of release version.
>
> Instead of...
>
> This extends up to the next major QGIS release following
>> the feature being merged*.
>
>
> Maybe something like...
>
> "This extends from when the feature is merged into a development branch
> until its public QGIS release containing the feature."
>
>
> 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."
>
> I'm all for accountability in code maintenance, but there has to be a
> limit. Otherwise, contributions may become viewed as indentured servitude.
>
> Regards,
>
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota
>
>
>> Nyall
>>
>>
>> >
>> >
>> > --
>> > Alessandro Pasotti
>> > w3:   www.itopen.it
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200311/0d00e678/attachment.html>