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

[Nyall Dawson]

On Mon, 8 Jun 2020 at 16: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.

I totally understand, and that's the main reason I've raised this. I
don't like informal policies or the feeling of "stepping beyond my
authority" either!

Nyall


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