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.
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.
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 <[email protected]
<mailto:[email protected]>> wrote:
On Wed, 11 Mar 2020 at 03:31, Alessandro Pasotti
<[email protected] <mailto:[email protected]>> 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 <http://www.itopen.it>
_______________________________________________
QGIS-Developer mailing list
[email protected] <mailto:[email protected]>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
