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

Thu Jun 18 05:41:40 PDT 2020

I'm +1 but I would recommend that there is also a vice-traffic-controller,
just in case the main one needs backup.

Cheers

On Thu, Jun 18, 2020 at 9:18 AM Andreas Neumann <andreas at qgis.org> wrote:

> Hi,
>
> Given that this affects mainly the core developers, I believe that PSC
> shouldn't just decide this on top of them without any discussion with our
> core developers. I would propose to send the proposal to the qgis-developer
> mailing list, allow some time for discussion and then decide.
>
> It is good that we have a volunteer with Nyall (and I think he would be a
> very good candidate), but we should allow other potential candidates.
>
> After that decision we should list the new role and person at
> https://www.qgis.org/en/site/getinvolved/governance/governance.html
>
> Would this make sense? Perhaps Marco or Jürgen (as a developer and PSC
> representative) could send the proposal to the qgis-developer mailing list?
>
> We can take some time here. There is no rush, but it would be good to
> decide shortly after the release these days. Before that release, people
> are super busy anway.
>
> Greetings,
> Andreas
>
> On Thu, 18 Jun 2020 at 08:06, Tim Sutton <tim at kartoza.com> wrote:
>
>> Hi
>>
>> +1 from me to do this using the wording of your original proposal below.
>> Just not sure who will be the person? Can we assume that you are
>> volunteering Nyall? In which case I would propose to just appoint Nyall
>> following the principle of using people who are actually motivated to do
>> things :-)
>>
>> Regards
>>
>> Tim
>>
>> On 17 Jun 2020, at 23:42, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>>
>>
>>
>>
>>
>>
>> ---
>>
>> *Tim Sutton*
>> tim at qgis.org
>>
>>
>>
>>
>> _______________________________________________
>> Qgis-psc mailing list
>> Qgis-psc at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
> --
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200618/49d05da1/attachment.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/20200618/49d05da1/attachment.png>