[Qgis-psc] [QGIS-Developer] Direct push forbidden to master

Tim Sutton tim at kartoza.com
Sun Nov 10 02:51:12 PST 2019


Hi

> 
> 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:
> - 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
> - 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)
> - my machine is faster than Travis
> - prepare-commit doesn't make all checks (spelling, others?)
> 
> 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
> 
> 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.
> 

I know we have raised the idea before and then blown it away, but it may be worth resurfacing: What about splitting QGIS up into a number of discrete libraries + the desktop app? Each could be in it’s own repo with it’s own CI and test suite. I know there are downsides to the approach (e.g. where should I report a bug?). We could still ‘fake’ the current QGIS repo using submodules so that the packaging etc. workflows are minimally affected (and maybe can take advantage of quick tweaks to packaging scripts etc without needing to wait for CI checks). Also developers wanting to work on e.g. providers could work in a more isolated environment. Anyway I know there were also good reasons not to do this so just raising the thought again in case over time it becomes more interesting.

Regards

Tim



> Cheers
> 



—


‘''






Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com <http://kartoza.com/> to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link <https://calendly.com/timlinux> to make finding time easy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191110/74710d1e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KartozaNewLogoThumbnail.jpg
Type: image/jpeg
Size: 6122 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20191110/74710d1e/attachment.jpg>


More information about the Qgis-psc mailing list