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

[Nyall Dawson]

On Sat, 6 Jun 2020 at 07:43, 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:

Any movement on this? Thinking more about the proposal, I think this
role is CRITICAL in the "landing" stage of a release (e.g. the week
leading up to a release). We need someone (authorised) to make the
hard call on which fixes are suitable for inclusion and which need to
be deferred till post release. (the last week is crucial here --
there's barely any time for fixes to be widely tested, so risk of last
minute regressions is extreme).

I'm doing this now, on a completely unauthorised basis (see eg
https://github.com/qgis/QGIS/pull/37044#issuecomment-645662038). And I
expect at some stage someone is going to "fight back" and rightly
question my authority to do this!

Nyall


>
> 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