<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi<div class=""><br class=""></div><div class=""><br class=""></div><div class="">After rereading the thread I think I am +1 for moving to RST in the QGIS Docs repo with the following thinking:</div><div class=""><br class=""></div><div class="">* all the good stuff Junior mentioned like translatability, visibility etc.</div><div class="">* when we hit release freeze we could copy the latest output from sphinx (maybe generated as plain text file?) to INSTALL.txt and remove the sources for the install docs from the QGIS code tree. That way the QGIS sources always contain the current notes for that release and the doc sources contain only the most recent procedure.</div><div class="">* we could add a note in the docs sources saying ‘these instructions are for the current state of the develop branch only, for version specific install procedures, please see the INSTALL.txt in the source tree for that release’</div><div class=""><br class=""></div><div class="">I think that workflow is not too much different from the current system. Of course someone needs to volunteer to get all the processes above into place :-P</div><div class=""><br class=""></div><div class="">@Jürgen regarding your comments below, I used to use apt-get build-dep too but I actually like the explicit package list your script generates more in some ways because it is deterministic compared to build-dep which will only reflect the deps from the current latest package in apt sources.</div><div class=""><br class=""></div><div class="">Regards</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Tim</div><div class=""><br class=""><blockquote type="cite" class="">On 17 May 2016, at 19:50, Richard Duivenvoorde <<a href="mailto:rdmailings@duif.net" class="">rdmailings@duif.net</a>> wrote:<br class=""><br class=""><br class="">Personally I'm ok with moving to rst / docs with the following arguments:<br class="">- it can be translated<br class="">- it is easier searchable (google)<br class="">- it will hopefully kept uptodate by more people because they try the<br class="">instructions and report back<br class=""><br class="">Only reason NOT doing it was because in an earlier hackfest (when I<br class="">already put them to rst), I thought Juergen told me something about<br class="">scripts which kept the files uptodate.<br class=""><br class="">IF only the apt-get lines are truely updated in that way, I'm ok with<br class="">moving.<br class=""><br class="">Plz others speak out.<br class=""><br class="">Regards,<br class=""><br class="">Richard<br class=""><br class="">On 17-05-16 11:46, DelazJ wrote:<br class=""><blockquote type="cite" class="">Hi all,<br class="">So, is any decision taken about this? Does it seem feasible?<br class=""><br class="">Regards,<br class="">Harrissou<br class=""><br class=""><br class="">2016-04-25 17:19 GMT+02:00 Jürgen E. <<a href="mailto:jef@norbit.de" class="">jef@norbit.de</a> <<a href="mailto:jef@norbit.de" class="">mailto:jef@norbit.de</a>>>:<br class=""><br class=""> Hi Richard,<br class=""><br class=""> On Sat, 23. Apr 2016 at 16:53:46 +0200, Richard Duivenvoorde wrote:<br class=""><blockquote type="cite" class="">@jef: maybe you can elaborate a little more on this?<br class=""></blockquote><br class=""> You're probably referring to scripts/scandeps.pl<br class=""> <<a href="http://scandeps.pl" class="">http://scandeps.pl</a>>. That updates the apt-get<br class=""> install lines in doc/linux.t2t from the packaging files in debian/<br class=""><br class=""> But that's about it. I'm not sure those are actually necessary -<br class=""> I'd try to<br class=""> keep specific versions from the descriptions if possible. As that's<br class=""> what tend<br class=""> to outdate quickly and point to the packaging files instead, because<br class=""> those are<br class=""> actually used and maintained.<br class=""><br class=""> BTW I for instance don't go through manually setting up the build<br class=""> with cmake<br class=""> for development, but produce packages once (or sometimes even kill<br class=""> the build<br class=""> half way) and keep using that build directory for development (both<br class=""> on linux<br class=""> and windows).<br class=""><br class=""> On Debian that complains about what dependencies are missing anyway<br class=""> - so having<br class=""> the apt-get install list above isn't necessary. You could also just<br class=""> add the<br class=""> nightly repository for the distribution you target and run apt-get<br class=""> build-dep<br class=""> qgis and achieve the same.<br class=""><br class=""><br class=""><br class=""> Jürgen<br class=""><br class=""> --<br class=""> Jürgen E. Fischer norBIT GmbH Tel.<br class=""> +49-4931-918175-31 <<a href="tel:%2B49-4931-918175-31" class="">tel:%2B49-4931-918175-31</a>><br class=""> Dipl.-Inf. (FH) Rheinstraße 13 Fax.<br class=""> +49-4931-918175-50 <<a href="tel:%2B49-4931-918175-50" class="">tel:%2B49-4931-918175-50</a>><br class=""> Software Engineer D-26506 Norden <br class=""> <a href="http://www.norbit.de" class="">http://www.norbit.de</a><br class=""> QGIS release manager (PSC) Germany IRC: jef on<br class=""> FreeNode<br class=""><br class=""> _______________________________________________<br class=""> Qgis-developer mailing list<br class=""> <a href="mailto:Qgis-developer@lists.osgeo.org" class="">Qgis-developer@lists.osgeo.org</a> <<a href="mailto:Qgis-developer@lists.osgeo.org" class="">mailto:Qgis-developer@lists.osgeo.org</a>><br class=""> List info: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" class="">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br class=""> Unsubscribe: <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" class="">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br class=""><br class=""><br class=""><br class=""><br class="">_______________________________________________<br class="">Qgis-community-team mailing list for organizing community resources such as documentation, translation etc..<br class=""><a href="mailto:Qgis-community-team@lists.osgeo.org" class="">Qgis-community-team@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-community-team<br class=""><br class=""></blockquote><br class="">_______________________________________________<br class="">Qgis-developer mailing list<br class=""><a href="mailto:Qgis-developer@lists.osgeo.org" class="">Qgis-developer@lists.osgeo.org</a><br class="">List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class="">Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer<br class=""></blockquote><br class=""><div class=""><span>—</span><br class=""><br class=""><br class=""><span><img height="118" width="150" apple-inline="yes" id="C05B53CC-44A8-43FE-B91F-99C0A9B90CCB" apple-width="yes" apple-height="yes" src="cid:1A5DF6DE-E302-4C28-BFBD-29663CBF1351" class=""></span><br class=""><br class=""><br class=""><br class="">Tim Sutton<br class=""><br class="">Co-founder: Kartoza<br class="">Project chair: <a href="http://qgis.org" class="">QGIS.org</a><br class=""><br class="">Visit http://kartoza.com to find out about open source:<br class=""><br class="">Desktop GIS programming services<br class="">Geospatial web development<br class="">GIS Training<br class="">Consulting Services<br class=""><br class="">Skype: timlinux <br class="">IRC: timlinux on #qgis at freenode.net<br class=""><br class=""><br class="">Kartoza is a merger between Linfiniti and Afrispatial<br class=""></div><br class=""></div></body></html>