<div dir="ltr"><div dir="ltr">Hi Nyall, et al.,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 10, 2020 at 4:55 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 11 Mar 2020 at 03:31, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br>
><br>
> I've always felt it was an implicit agreement, but I totally agree<br>
> that making it explicit is a good idea.<br>
<br>
Yep, it's been more or less "understood" practice for some time, but<br>
I'd like it to be official so there's no room for misunderstand.<br>
<br>
> Where exactly would you suggest to add that kind of statements?<br>
<br>
I'd put it in a new section under<br>
<a href="https://docs.qgis.org/testing/en/docs/developers_guide/" rel="noreferrer" target="_blank">https://docs.qgis.org/testing/en/docs/developers_guide/</a>  Maybe<br>
something like "development policies"?<br>
<br>
We could word it something like:<br>
<br>
"While new feature submissions are always highly appreciated, every<br>
feature added to QGIS comes with an associated maintenance burden for<br>
the project. Accordingly, some policies exist to avoid placing this<br>
burden on the existing QGIS development team:<br>
- Following any new feature development, it is the original<br>
developer's (or organisations) SOLE responsibility to proactively<br>
monitor and implement bug fixes relating to the new feature (or<br>
regressions to other parts of QGIS which have resulted from its<br>
development). This extends up to the next major QGIS release following<br>
the feature being merged*. It is NOT acceptable to use QGIS.org<br>
sponsored bug fixing efforts to implement these fixes. Failure to<br>
provide fixes to all reasonable bug reports raised for a<br>
new feature may lead to that feature being reverted prior to release.<br>
</blockquote><div><br></div><div>Need some clarification on some particulars related to versioning and releases...</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regardless, I suggest scheduling the expected new feature support relative to the public release *cadence*, regardless of release version.</div><div><br></div><div><div>Instead of...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This extends up to the next major QGIS release following<br>
the feature being merged*.</blockquote></div><div><br></div><div>Maybe something like...</div><div><br></div><div>"This extends from when the feature is merged into a development branch until its public QGIS release containing the feature."</div><div><br></div><div><br></div><div>Also ...</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">- After this major release, the developer is still expected to monitor<br>
the bug tracker for issues relating to their work and implement<br>
reasonable fixes at their own expense.<br>
"<br></blockquote><div></div></div><div><br></div><div>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'?</div><div><br></div><div>Maybe instead:</div><div><br></div><div>"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."</div><div><br></div><div>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."</div><div><br></div><div>I'm all for accountability in code maintenance, but there has to be a limit. Otherwise, contributions may become viewed as indentured servitude.</div><div><br></div><div>Regards,</div><div><br></div><div>Larry Shaffer<br>Dakota Cartography<br>Black Hills, South Dakota<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nyall<br>
<br>
<br>
><br>
><br>
> --<br>
> Alessandro Pasotti<br>
> w3:   <a href="http://www.itopen.it" rel="noreferrer" target="_blank">www.itopen.it</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div></div>