<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi<div class=""><br class=""><blockquote type="cite" class="">On 20 Jun 2016, at 17:59, Jürgen E. Fischer <<a href="mailto:jef@norbit.de" class="">jef@norbit.de</a>> wrote:<br class=""><br class="">Hi Tim,<br class=""><br class="">On Mon, 20. Jun 2016 at 16:35:40 +0200, Tim Sutton wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Compare this to the impression one gets from using QGIS when it comes to<br class="">the application (which is widely perceived as user friendly from what I<br class="">hear) or looking at the QGIS homepage or listening to QGIS presentations.<br class="">We have great, professional looking material.<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Let's face it. It's 2016. It's time to move on.<br class=""></blockquote></blockquote><br class=""><blockquote type="cite" class="">I’m in the ‘don’t think mantras are a good approach’ camp too. I believe<br class="">Jürgen is going to work with you guys (in particular Giovanni and Matthias)<br class="">to get a migration path to GH Issues so that we don’t need to make users deal<br class="">with OSGEO sign up process + have the benefit of a nice modern issue tracker.<br class=""></blockquote><br class="">Um, that implies that I'm already sold on the idea that we should be using gh<br class="">for tickets. I'm not sure we need to switch the ticket system again.<br class=""></blockquote><div class=""><br class=""></div><div class="">Yeah sorry I realise you are not sold on the idea so it would have been better stated to say that you would work with Giovanni and Matthias to come up with a way forward. Personally I hope that way includes GitHub but its for you to figure out. The main thing is to get out of the circular discussion we are currently in about how to move forward with the issue tracker - hopefully that is something the three of you can resolve.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class="">I guess it's more the hosting and not redmine itself that makes it slow - and I<br class="">believe that's the main point why we consider to switch.<br class=""></blockquote><div class=""><br class=""></div><div class="">I don’t think that is the main / only point (again at the risk of circular discussions):</div><div class=""><br class=""></div><div class="">* redmine is slow in its workflows - in GH is very easy to just drag and drop a screenshot and sample data attachment straight into the issue text. Also the markup system in GH is IMHO faster since it is used in many places and so you don’t have to read wiki formatting docs if you haven’t used the tracker in a while. GH is also fast in its architecture - it doesn’t require full page reload for each interaction.</div><div class=""><br class=""></div><div class="">* the OSGEO sign up process (mantra or not) is terrible</div><div class=""><br class=""></div><div class="">* redmine is another piece of infrastructure we have to manage - it would be nice to reduce that. I don’t even know if we have backups for redmine running?</div><div class=""><br class=""></div><div class="">* I think there is a general desire to also not be providing hosting and bug trackers for plugins - although I guess we don’t need to migrate our own tracker in that case, just shut down others.</div><div class=""><br class=""></div><div class="">* I think there were other concerns which I have probably forgotten here in my list above</div><div class=""><br class=""></div><div class="">As has been pointed out, maybe a more modern Redmine addresses some of these issues, in which thats fine for me, but my point is please consider other benefits that could be had by moving / upgrading / a hosted solution, not just page load speed.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class="">And I doubt tags only are better suited to classify a massive amount of tickets<br class="">like ours than what redmine offers. But I have neither experience with using<br class="">redmine for anything else but QGIS and no experience with using gh with many<br class="">tickets.<br class=""></blockquote><div class=""><br class=""></div><div class="">Docker is a nice example where they have > 10000 issues and they seem to manage the queue well. I think the general search capability of GH Issues is pretty good which combined with tags and filters on user name etc. generally let you find stuff pretty well… <a href="https://github.com/docker/docker/issues" class="">https://github.com/docker/docker/issues</a></div><br class=""><blockquote type="cite" class=""><br class="">Matthias' script IMHO looses too much information we have in rm - and trying to<br class="">do more - back in April - I quickly ran into gh's api throtteling. IIRC there<br class="">was also didn't find a way to attribute stuff to the original<br class="">submitter/commenter. <br class=""></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I think Matthias is/was offering to address any specific issues if we can give him a list of what we need (and Nathan has been offering his help too).</div><br class=""><blockquote type="cite" class=""><br class="">That also points to the fact that gh is proprietary service - which is another<br class="">thing I have issues with - IMHO a route we should be careful about. For git<br class="">that doesn't matter - but for issues (and that also goes for PRs) it does.<br class=""></blockquote><div class=""><br class=""></div><div class="">Yup being on an open platform is always nice, so I concede your point on that one. That said, it isn’t a blocker for me as we also get the benefits of it being continuously improved, robust infrastructure and an API that we can use to extract our data off the site again if we want to (as you mention below).</div><br class=""><blockquote type="cite" class=""><br class="">gh is of course much easier for us to use - because we don't have to worry<br class="">about hosting, scalabilility and administration - which one of gh's big<br class="">plus. Integration is another - but that cuts both ways.<br class=""></blockquote><div class=""><br class=""></div><div class="">Yup. </div><div class=""><br class=""></div><div class="">Anyway I hope you, Giovanni and Matthias can come up with a plan that at least gives us some more headroom for the next few years on the bug tracker side of things. I thing that whatever you decide, we should still plan on deprecating hosting issue trackers and git repos for plugins so that we only have to focus on our own tracker. </div><div class=""><br class=""></div><div class="">I’ll butt out and let you all figure it out :-)</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><br class=""><br class="">Jürgen<br class=""><br class="">PS: BTW the odd mantra thing is just temporary.<br class=""><br class="">-- <br class="">Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31<br class="">Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50<br class="">Software Engineer D-26506 Norden <a href="http://www.norbit.de" class="">http://www.norbit.de</a><br class="">_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc<br class=""></blockquote><br class=""><div class=""><span><img height="65" width="59" apple-inline="yes" id="C108914F-510A-4C87-9ABD-368F2F822F1A" apple-width="yes" apple-height="yes" src="cid:879A6E78-CA46-47B2-AA0E-1810BD833229" class=""></span><br class=""><br class=""><br class="">---<br class=""><br class="">Tim Sutton<br class="">QGIS Project Steering Committee Chair<br class=""><a href="mailto:tim@qgis.org" class="">tim@qgis.org</a><br class=""><br class=""><br class=""><br class=""></div><br class=""></div></body></html>