<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 9, 2019 at 2:48 PM Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</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>
<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></div></blockquote><div><br></div><div><br></div><div>Hi Matthias, <br></div><div><br></div><div>I totally agree with your last claim: I think we must all go through PRs and this is what "normally" everyone does, but I see a very few and limited cases when a direct commit to master is the right thing to do and I recommend to leave that door open.</div><div><br></div><div>A stupid example is fixing a typo in a comment, to be honest if I need to branch and create a PR and go through Travis I will just leave the typo (if that's not part of something I'm still working on). Of course, sticking to this stupid example, this also means that after fixing this typo in the comment if master is broken I won't go to sleep until I fixed it.</div><div><br></div><div>As I've already mentioned I don't see a problem here, 99.99% of the workflow goes through Travis and in the few exceptional cases when it doesn't, if master was broken it was fixed almost immediately, in any event I don't see a big issue if master is broken for some time provided that who breaks it also takes the responsibility to fix it quickly.<br></div><div><br></div>Speaking of Travis, I've found it a life-saver many times but I also think that given the amount of time we spent on it we could have rewritten QGIS in nodejs (because this is the long term plan, isn't it?) but without a better alternative we must live with it. <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Just one thing I would recommend investing a bit more time and money: to be able to run a Travis-like test suite locally (I was able to do it but it costed me a lot of time to set up and to understand how to use it, I definitely don't use it regularly), here are the reasons:</div><div class="gmail_quote">- branch switch costs time, and I'm often working on several fixes/features at the same time, waiting for Travis to know that it failed because of (say) a silly typo in a comment is a huge waste of time</div><div class="gmail_quote">- sometimes being able to debug the Travis locally is the only option (I know there is way to ssh into remote Travis but that's a bit complicated and slow)</div><div class="gmail_quote">- my machine is faster than Travis<br></div><div class="gmail_quote">- prepare-commit doesn't make all checks (spelling, others?)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cutting down build times would also help but I don't have any real proposal here, I've read somewhere that other build systems might be faster and that pre-compiled header might help but I'm not an expert in this field<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">So, IMHO long life to PRs and Travis for the time being but we need to give to the developers the tools to run locally all checks that Travis runs remotely so that they are reasonably sure ("reasonably" because Travis random unrelated failures are always around the corner) that the build will pass and they will be able to debug a Travis failure locally without waiting for hours.<br></div><div class="gmail_quote"></div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
</p>
<p>-- Matthias<br>
</p>
<div>On 11/8/19 1:23 PM, Nathan Woodrow
wrote:<br>
</div>
<blockquote type="cite">
<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" target="_blank">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">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">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">http://www.spatialys.com</a><br>
_______________________________________________<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>
<fieldset></fieldset>
<pre>_______________________________________________
Qgis-psc mailing list
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></pre>
</blockquote>
</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" class="gmail_signature">Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>