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

Tim Sutton tim at kartoza.com
Fri Jun 5 16:23:55 PDT 2020


Hi

A sábado, 6 de jun de 2020, 00:20, Nyall Dawson <nyall.dawson at gmail.com>
escreveu:

> On Sat, 6 Jun 2020 at 09:13, Tim Sutton <tim at kartoza.com> wrote:
> >
> > Hi
> >
> > Great idea! I always hoped that QGIS.org would eventually form a group
> of paid contributors who keep all the machinery of the project running
>
> Hey Tim!
>
> Just to clarify -- I wasn't proposing this as a paid position. Just a
> position with authority blessed by the PSC to make the tough calls
> when they're needed!
>

Yes I understood that thanks, though my comments still apply! And thanks
for all the work that you, Matthias, Ale and Denis have already been doing!

Regards

Tim


> Nyall
>
> > - eventually building up to having full time paid employees doing a lot
> of the grunt work for the project so that volunteers can do the ‘fun’
> stuff. Many other open source projects have followed this route with
> success. See for example how KDE recently recruited a marketing person:
> https://ev.kde.org/resources/marketingsupport-callforproposals-2020.pdf
> >
> > Also maybe if the candidates that Nyall suggests are a bit busy this
> work could be split between them e.g. on a rotational basis.
> >
> > Regards
> >
> > Tim
> >
> >
> >
> > On 5 Jun 2020, at 22: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:
> >
> > 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
> >
> >
> > —
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Tim Sutton
> >
> > Co-founder: Kartoza
> > Ex Project chair: QGIS.org
> >
> > Visit http://kartoza.com to find out about open source:
> >
> > Desktop GIS programming services
> > Geospatial web development
> > GIS Training
> > Consulting Services
> >
> > Skype: timlinux
> > IRC: timlinux on #qgis at freenode.net
> >
> > I'd love to connect. Here's my calendar link to make finding time easy.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200606/dde5e790/attachment.html>


More information about the Qgis-psc mailing list