<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Alessandro<br>
</p>
<div class="moz-cite-prefix">On 11/10/19 9:20 AM, Alessandro Pasotti
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAL5Q6715Run1PX7Ana1EFjQBcLDwkUG7=Z74wnoG3BWsK+J=xQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><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"
moz-do-not-send="true">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>
</div>
</blockquote>
<p>I am sorry to disagree on this first part. I don't think this
warrants a direct push. I don't even think it saves time. I
usually don't have a clean master checked out in this scenario, so
I still need to add a separate worktree where I can cherry-pick
something and then I can as well just push it to a new PR branch
that lets me figure out if this introduced a new typo or if I
forgot to sync the changes to sip.<br>
</p>
<blockquote type="cite"
cite="mid:CAL5Q6715Run1PX7Ana1EFjQBcLDwkUG7=Z74wnoG3BWsK+J=xQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</blockquote>
<p>Integrating more static tests in the pre-commit hook sounds like
a very good idea (i.e. the typo checks you mention).</p>
<p>It would also be nice to improve the possibilities to run the CI
containers locally. It will still be tough to debug because it's
not directly on the system but inside a container (i.e. no direct
IDE debugger integration), but I can definitely see some
advantages there.<br>
</p>
<blockquote type="cite"
cite="mid:CAL5Q6715Run1PX7Ana1EFjQBcLDwkUG7=Z74wnoG3BWsK+J=xQ@mail.gmail.com">
<div dir="ltr">
<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>
</blockquote>
<p>There's some interesting recent information on this too
<a class="moz-txt-link-freetext" href="https://www.qt.io/blog/2019/08/01/precompiled-headers-and-unity-jumbo-builds-in-upcoming-cmake">https://www.qt.io/blog/2019/08/01/precompiled-headers-and-unity-jumbo-builds-in-upcoming-cmake</a></p>
<blockquote type="cite"
cite="mid:CAL5Q6715Run1PX7Ana1EFjQBcLDwkUG7=Z74wnoG3BWsK+J=xQ@mail.gmail.com">
<div dir="ltr">
<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"><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" 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></fieldset>
<pre>_______________________________________________
Qgis-psc mailing list
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank" moz-do-not-send="true">Qgis-psc@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank" moz-do-not-send="true">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"
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 clear="all">
<br>
-- <br>
<div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>
w3: <a href="http://www.itopen.it" target="_blank"
moz-do-not-send="true">www.itopen.it</a></div>
</div>
</blockquote>
</body>
</html>