[Qgis-psc] Request for appointing a formal release "traffic controller" role

[Tim Sutton]

Hi

> On 8 Jun 2020, at 07:38, Alessandro Pasotti <apasotti at gmail.com> wrote:
> 
> Hi Nyall,
> 
> Thank you for raising the issue, I agree that we need to make the
> policy explicit (and discuss it if there is no consensus).
> 
> I also agree that we need someone that makes the decisions in case
> it's not clear or there is no agreement on if a commit can be
> dangerous to backport.
> 
> The most important thing is that we write this policy down somewhere
> (the developers documentation?), it's just frustrating that one needs
> to respect a list of unwritten rules that haven't been discussed or
> approved by the community.

Yes you are right. Maybe the process should be to first vote on it in PSC if needed and note it in 

https://qgis.org/en/site/getinvolved/governance/resolutions/2020_resolutions.html?highlight=resolutions

And then secondly start a ‘Community Rules and Standards’ page or similar where we lay out all these things in one place.  Another candidate for recording this could be:

https://qgis.org/en/site/getinvolved/governance/governance.html?highlight=roles

Regards

Tim


> 
> Cheers
> 
> On Fri, Jun 5, 2020 at 11:43 PM Nyall Dawson <nyall.dawson at gmail.com> wrote:
>> 
>> Hi PSC,
>> 
>> I'd like to raise the notion that qgis.org appoint a formal position
>> for a release "traffic controller". This role would be responsible
>> for:
>> 
>> 1. Making the final call on what is suitable for backporting to stable releases
>> 2. Guide formal policy regarding the different stages in the lifetime
>> of an LTR release, and develop written guidelines on what is
>> acceptable to backport at different patch releases for an LTR
>> 3. Make the final call on feature freeze exemptions during a
>> pre-release freeze period.
>> 
>> Some clarifications:
>> - This role would be distinct from the release manager position, which
>> is currently responsible for making QGIS releases, release packaging
>> and release cycles. This would be a time-intensive role, and I don't
>> think it should be added to the already (time-intensive) duties of the
>> release manager position.
>> - It would be a highly technical, very hands-on role, requiring
>> **daily/bi-daily** monitoring of the pull request queue and issue
>> tracker and full knowledge across all different parts of the QGIS
>> codebase and the interplay between them (and the risks associated with
>> changes). It is NOT a "project manager for QGIS" type role!
>> - It would be a formal community role appointed by PSC, not a position
>> on the PSC/board itself
>> 
>> I'm raising this now after reflecting on the recent informal practice
>> that Matthias Kuhn and I have been trialling where non-crash,
>> non-data-corruption, non-trivial fixes get put into a "time delay"
>> before being allowed to included in an LTR patch release. (see
>> https://github.com/qgis/QGIS/pull/36718,
>> https://github.com/qgis/QGIS/pull/36812). By doing this, we ensure
>> that these fixes have exposure in a standard (non LTR) release for at
>> least one month before they get included in the LTR release. The
>> intention is to dramatically reduce the risk of regressions being
>> introduced in the middle of an LTR release. (When this happens, it
>> undermines user/enterprise confidence in the LTR process and reflects
>> poorly on QGIS). This is a completely informal policy we developed and
>> wanted to trial, and while I totally stand behind it and think it's a
>> great way approach it makes me nervous that Matthias and I have
>> basically just forced this policy ourselves. See
>> https://github.com/qgis/QGIS/pull/36718#issuecomment-639428003 for
>> discussion on this whether this policy is acceptable or not.
>> 
>> IMO, suitable candidates would be developers with extensive experience
>> across a whole range of areas of the QGIS code, and demonstrated
>> history of timely reviews and responses to comments on github. I would
>> suggest that suitable candidates, (based on activity on github over
>> the past 12+ months and commits ranging across all areas of QGIS) are:
>> - Matthias
>> - Alessandro
>> - Denis
>> - (myself)
>> 
>> Thanks for your consideration!
>> Nyall
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
> 
> 
> 
> -- 
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

 




---

Tim Sutton
tim at qgis.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200608/5b454c53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qgis-icon-60x60.png
Type: image/png
Size: 4401 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200608/5b454c53/attachment-0001.png>