<div dir="ltr"><div>Hi,</div><div><br></div><div>In the early days of QGIS, when Marco H. and Otto had been in the PSC, we had a role called "technical advisor" (or similar, I don't remember the exact term). Perhaps, we can resurrect that role and among others, the "technical advisor" would be responsible for:</div><div><br></div><div>---- citation Nyall --------<br></div><div>1. Making the final call on what is suitable for backporting to stable releases<br>2. Guide formal policy regarding the different stages in the lifetime<br>of an LTR release, and develop written guidelines on what is<br>acceptable to backport at different patch releases for an LTR<br>3. Make the final call on feature freeze exemptions during a<br>pre-release freeze period.</div><div>--------------------------------</div><div><br></div><div>Just an idea.</div><div><br></div><div>Greetings,</div><div>Andreas<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 18 Jun 2020 at 14:41, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com">apasotti@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I'm +1 but I would recommend that there is also a vice-traffic-controller, just in case the main one needs backup.</div><div><br></div><div>Cheers<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 18, 2020 at 9:18 AM Andreas Neumann <<a href="mailto:andreas@qgis.org" target="_blank">andreas@qgis.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>After that decision we should list the new role and person at <a href="https://www.qgis.org/en/site/getinvolved/governance/governance.html" target="_blank">https://www.qgis.org/en/site/getinvolved/governance/governance.html</a></div><div><br></div><div>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?</div><div><br></div><div>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.<br></div><div><br></div><div>Greetings,</div><div>Andreas<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 18 Jun 2020 at 08:06, Tim Sutton <<a href="mailto:tim@kartoza.com" target="_blank">tim@kartoza.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi<div><br></div><div>+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 :-)</div><div><br></div><div>Regards</div><div><br></div><div>Tim<br><div><br><blockquote type="cite"><div>On 17 Jun 2020, at 23:42, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:</div><br><div><div>On Sat, 6 Jun 2020 at 07:43, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br><blockquote type="cite"><br>Hi PSC,<br><br>I'd like to raise the notion that <a href="http://qgis.org" target="_blank">qgis.org</a> appoint a formal position<br>for a release "traffic controller". This role would be responsible<br>for:<br></blockquote><br>Any movement on this? Thinking more about the proposal, I think this<br>role is CRITICAL in the "landing" stage of a release (e.g. the week<br>leading up to a release). We need someone (authorised) to make the<br>hard call on which fixes are suitable for inclusion and which need to<br>be deferred till post release. (the last week is crucial here --<br>there's barely any time for fixes to be widely tested, so risk of last<br>minute regressions is extreme).<br><br>I'm doing this now, on a completely unauthorised basis (see eg<br><a href="https://github.com/qgis/QGIS/pull/37044#issuecomment-645662038" target="_blank">https://github.com/qgis/QGIS/pull/37044#issuecomment-645662038</a>). And I<br>expect at some stage someone is going to "fight back" and rightly<br>question my authority to do this!<br><br>Nyall<br><br><br><blockquote type="cite"><br>1. Making the final call on what is suitable for backporting to stable releases<br>2. Guide formal policy regarding the different stages in the lifetime<br>of an LTR release, and develop written guidelines on what is<br>acceptable to backport at different patch releases for an LTR<br>3. Make the final call on feature freeze exemptions during a<br>pre-release freeze period.<br><br>Some clarifications:<br>- This role would be distinct from the release manager position, which<br>is currently responsible for making QGIS releases, release packaging<br>and release cycles. This would be a time-intensive role, and I don't<br>think it should be added to the already (time-intensive) duties of the<br>release manager position.<br>- It would be a highly technical, very hands-on role, requiring<br>**daily/bi-daily** monitoring of the pull request queue and issue<br>tracker and full knowledge across all different parts of the QGIS<br>codebase and the interplay between them (and the risks associated with<br>changes). It is NOT a "project manager for QGIS" type role!<br>- It would be a formal community role appointed by PSC, not a position<br>on the PSC/board itself<br><br>I'm raising this now after reflecting on the recent informal practice<br>that Matthias Kuhn and I have been trialling where non-crash,<br>non-data-corruption, non-trivial fixes get put into a "time delay"<br>before being allowed to included in an LTR patch release. (see<br><a href="https://github.com/qgis/QGIS/pull/36718" target="_blank">https://github.com/qgis/QGIS/pull/36718</a>,<br><a href="https://github.com/qgis/QGIS/pull/36812" target="_blank">https://github.com/qgis/QGIS/pull/36812</a>). By doing this, we ensure<br>that these fixes have exposure in a standard (non LTR) release for at<br>least one month before they get included in the LTR release. The<br>intention is to dramatically reduce the risk of regressions being<br>introduced in the middle of an LTR release. (When this happens, it<br>undermines user/enterprise confidence in the LTR process and reflects<br>poorly on QGIS). This is a completely informal policy we developed and<br>wanted to trial, and while I totally stand behind it and think it's a<br>great way approach it makes me nervous that Matthias and I have<br>basically just forced this policy ourselves. See<br><a href="https://github.com/qgis/QGIS/pull/36718#issuecomment-639428003" target="_blank">https://github.com/qgis/QGIS/pull/36718#issuecomment-639428003</a> for<br>discussion on this whether this policy is acceptable or not.<br><br>IMO, suitable candidates would be developers with extensive experience<br>across a whole range of areas of the QGIS code, and demonstrated<br>history of timely reviews and responses to comments on github. I would<br>suggest that suitable candidates, (based on activity on github over<br>the past 12+ months and commits ranging across all areas of QGIS) are:<br>- Matthias<br>- Alessandro<br>- Denis<br>- (myself)<br><br>Thanks for your consideration!<br>Nyall<br></blockquote>_______________________________________________<br>Qgis-psc mailing list<br><a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></div></div></blockquote></div><br><div>
<span style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-size:18px"> </span><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span><img id="gmail-m_9089891218401868695gmail-m_7719866079042630987gmail-m_4872602229540348161F84695AB-7BC4-4CDA-8CBD-E93B82451DFE" src="cid:172c628441f21f772cc1"></span><div style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-size:12px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal"><div style="font-weight:normal"><br><br><br><br>---</div><div style="font-weight:normal"><br></div><div><b>Tim Sutton</b></div><div style="font-weight:normal"><a href="mailto:tim@qgis.org" target="_blank">tim@qgis.org</a></div><div style="font-weight:normal"><br></div></div><br style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-size:12px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal;line-height:normal"><br style="color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-size:12px;font-variant-ligatures:normal;font-variant-numeric:normal;font-variant-alternates:normal;font-variant-east-asian:normal">
</span></div>
<br></div></div>_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><br>--<br>Andreas Neumann<br></div><a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> board member (treasurer)<br></div></div>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div>Alessandro Pasotti</div><div>QCooperative: <a href="https://www.qcooperative.net" target="_blank">www.qcooperative.net</a><br></div>ItOpen: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br>--<br>Andreas Neumann<br></div><a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> board member (treasurer)<br></div></div>