[QGIS-Developer] Explicit policy re bug fixing responsibilities after new features
Nyall Dawson
nyall.dawson at gmail.com
Tue Mar 10 15:59:06 PDT 2020
On Tue, 10 Mar 2020 at 20:30, Régis Haubourg <regis.haubourg at gmail.com> wrote:
>
> Hi Nyall,
> this sounds reasonable indeed, can we have a bit more background or pointers to real cases?
There's been a lot of "drive by features" over the last 12 months,
where we see work merged and then the original developer disappears. A
decent number of these have been first time QGIS developers. I'd
rather not point to individual cases if that's ok!
> One issue we faced these past months is that he exponential trafic on the issues and PR makes it harder to follow issues and just have the information that we could possibly be at stake somewhere.
> Last year I was able to follow +/- 80 % of the discussions. I must admit that lastly it became nearly impossible unless to work mostly on QGIS bug triaging or coding.
Yep, I hear you here! The PR queue is really stacking up again now and
stressing me out...
Nyall
>
> I really don't know how we could improve our communication channels. Any hint welcome.
>
> Best regards
> Régis
>
> Le lun. 9 mars 2020 à 23:14, Nyall Dawson <nyall.dawson at gmail.com> a écrit :
>>
>> Hi list,
>>
>> I'm after feedback on whether or not others think an explicit
>> policy/contract regarding bug fixing responsibilities for new features
>> is a good idea or not.
>>
>> I would like to see something like this added to the developer guidelines:
>>
>> "Following any new feature development, it is the original developer's
>> (or organisations) SOLE responsibility to 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."
>>
>> *i.e. currently 3.14
>>
>> Personally, I think having this as part of our developer agreement
>> would help clear up some ambiguity and source of frustration/conflict
>> between developers.
>>
>> Thoughts?
>>
>> Nyall
>> _______________________________________________
>> 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
More information about the QGIS-Developer
mailing list