<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi,</p>
    <p>I think this discussion was triggered partially at least by my
      refactoring of the cmake build system. I am sorry for any
      inconveniences that this triggered and hope it's justified by the
      long term simplification that should come out of this.</p>
    <p>Overall I see three different topics. One is the request for a
      Windows based CI, one is a rant over travis and CI in general and
      one is the question if direct pushes to master should be allowed
      (and encouraged).</p>
    <p>A Windows based CI would in my opinion be highly desirable. I
      cannot see any reason not to do it actually. Most users run QGIS
      on Windows, that's just the reality. And we want QGIS to run
      stable on Windows. The questions that remain is how much $$ the
      infrastructure and it's setup is and if we get a Windows build
      system to complete in a reasonable time. I don't think nightly
      builds are equivalent, last week they were broken and it was up to
      one single person (Jürgen) to fix this. If a CI had been in place
      it would have been my job to fix the build before it is merged
      into our codebase, which would have been much more convenient for
      everyone. We also don't need all tests to pass on Windows to put
      this into play. We can blacklist some tests and gradually fix
      remaining ones. We have done that before on other platforms too.</p>
    <p>If Travis (or any CI) is worth the effort is indeed a question
      that can and should be asked. It does require a lot of time to
      keep it up and running. What it provides on the other hand is an
      early feedback of regressions. And early in this case means
      detecting them before they even are in the codebase. This saves
      valuable time from our testers which can instead focus on testing
      things which have not been detected by the CI. And it saves time
      of core developers who don't need to fix bugs introduced by
      others. It also makes it easier to fix bugs because they are
      related to a particular pull request and context. Yes, travis also
      bitches around sometime and makes us loose time. I can't give a
      definite answer but in comparison with the wild west style before
      I am in favor of our CI.</p>
    <p>Pushing directly to master is not a complete disaster, but I
      can't see many advantages of doing it. So far it's sort of a
      gentlemen agreement that most don't push directly to master. I
      don't remember the last time I did it actually. I am fine with
      restricting and enforcing this on github but if that's not desired
      by the PSC / Jürgen, I would like to appeal to everyone to keep
      away from doing direct pushes. Waiting an hour for a green tick
      shouldn't be asked too much.<br>
    </p>
    <p>-- Matthias<br>
    </p>
    <div class="moz-cite-prefix">On 11/8/19 1:23 PM, Nathan Woodrow
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAAi8Yg8jQ1n4O3m+O3knHqCpRMpwio1_6zud_=WBi01NCEzYZA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">I agree with Even.  The issue here is the slow CI
        builds and lack of Windows CI builds.  
        <div>To make this process smoother and more solid for everyone
          we need to invest in better CI not pretend we can just ignore
          it for the sake of getting a commit in..
          <div><br>
          </div>
          <div>- Nathan</div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, Nov 8, 2019 at 10:05
          PM Even Rouault <<a
            href="mailto:even.rouault@spatialys.com"
            moz-do-not-send="true">even.rouault@spatialys.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">On
          vendredi 8 novembre 2019 19:32:06 CET Nyall Dawson wrote:<br>
          > On Fri, 8 Nov 2019 at 18:33, ElPaso <<a
            href="mailto:elpaso@itopen.it" target="_blank"
            moz-do-not-send="true">elpaso@itopen.it</a>> wrote:<br>
          > > I'm with Jürgen on this, I think we all are
          responsible developers<br>
          > > acting for the good of QGIS and I didn't see any
          abuse on direct commits<br>
          > > in the past few years.<br>
          > > <br>
          > > <br>
          > > On the contrary, I think I should have committed to
          master directly to<br>
          > > correct a PR of mines that I merged by mistake the
          day before 3.10<br>
          > > release (<a
            href="https://github.com/qgis/QGIS/pull/32369"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/qgis/QGIS/pull/32369</a>)
          instead of waiting for<br>
          > > an approval that didn't arrive in time (in this case
          it wasn't really a<br>
          > > big problem though).<br>
          > <br>
          > I don't think Denis is arguing for forced-reviews of pull
          requests.<br>
          > Rather just that all changes GO through pull requests so
          that we can<br>
          > be sure they don't break CI.<br>
          <br>
          What is obvious here is that a CI for Windows would avoid
          avoided this case, <br>
          as the cost of maintaining the Windows build alive mostly
          relies on a single <br>
          person currently.<br>
          As it seems that most QGIS users run Windows, it might be
          worth for the <br>
          project to invest into that, both in funding the time of the
          folks who would <br>
          set up that and possibly paying for a beefy enough server
          (potentially from a <br>
          commercial CI hosting solution) that would sustain the load of
          pull requests.<br>
          <br>
          And paying for Travis extra build could potentially save time
          for a number of <br>
          contributors. For the github OSGeo organization, mostly used
          by PROJ & GDAL, <br>
          it is between 4000-5000 USD/year for 11 parallel builds (this
          includes a <br>
          discount for OSGeo being a non-profit). There might be cheeper
          alternatives by <br>
          other competitors.<br>
          <br>
          -- <br>
          Spatialys - Geospatial professional services<br>
          <a href="http://www.spatialys.com" rel="noreferrer"
            target="_blank" moz-do-not-send="true">http://www.spatialys.com</a><br>
          _______________________________________________<br>
          Qgis-psc mailing list<br>
          <a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank"
            moz-do-not-send="true">Qgis-psc@lists.osgeo.org</a><br>
          <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Qgis-psc mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-psc@lists.osgeo.org">Qgis-psc@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-psc">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></pre>
    </blockquote>
  </body>
</html>