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

[Alessandro Pasotti]

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.

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