<div dir="ltr"><div>Hi,<br><br></div>I don't think splitting development resources to maintain an LTS branch is going to solve the real issues. In fact, it will probably just cause more.<br><div><div><div class="gmail_extra">
<br></div><div class="gmail_extra">It seems to me that it all boils down to needing more time between releases:<br><br>* Documentation and development teams need to work more together = more time needed<br></div><div class="gmail_extra">
* Developers need to squash more bugs = more time (and funding) needed<br></div><div class="gmail_extra">* Users and trainers need to fully adopt and use a specific version = more time needed</div><div class="gmail_extra">
<br></div><div class="gmail_extra">I propose just extending the current 4 month release scenario to ** 6 months **, i.e. just two releases a year. With all dev and freeze cycles expanding proportionally.<br><br></div><div class="gmail_extra">
Surely, knowing that QGIS is only/always released twice a year is enough to tailor training and course material and help the documentation team keep current. Surely, having more time to polish the code base and squash bugs will help with stability.<br>
<br></div><div class="gmail_extra">Why do developers need a faster schedule than 6 months to produce new features quicker if the rest of the community finds that too fast, and can't keep up? What's the point then?<br>
<br></div><div class="gmail_extra">With more time and resources focusing on one (and only one) branch, we should be able to overcome the current situation that is causing complications for users, trainers, documenters, translators and sponsors. Splitting dev resources between different branches, or only doing extra bug fixing at certain times of the year will not fix these ongoing issues of the development-release cycle going too fast for the rest of the community.<br>
<br></div><div class="gmail_extra">The current, too-quick 4-month release schedule is obviously NOT working out.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,<br clear="all"></div><div class="gmail_extra">
<div><br>Larry Shaffer<br>Dakota Cartography<br>Black Hills, South Dakota</div>
<br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 3:10 PM, Bernd Vogelgesang <span dir="ltr"><<a href="mailto:bernd.vogelgesang@gmx.de" target="_blank">bernd.vogelgesang@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<u></u>
<div style="font-family:Helvetica,Arial,sans-serif;font-size:13px">Am 22.07.2014, 12:16 Uhr, schrieb Derek Hohls <<a href="mailto:dhohls@csir.co.za" target="_blank">dhohls@csir.co.za</a>>:<div class=""><br><br><blockquote style="margin:0px 0px 0.8ex;border-left:2px solid rgb(0,0,255);padding-left:1ex">
Is it not possible to require an absolutely minimum entry, at the correct place in the docs, for a new feature? For example, if a developer adds a new function X to a list of existing functions, already documented in section M.N, then at a minimum they need to add an entry saying "Function X (added 22/7/14): TBD". Anyone wanting to contribute to the docs can then (hopefully) easily search for undocumented features, both recent or ancient. It may even be possible to organise "doc sprints" based on this approach.<br>
</blockquote></div><div><div>+1 !</div><div><br></div></div><div class=""><div><br></div><div><br></div><div><br></div><blockquote style="margin:0px 0px 0.8ex;border-left:2px solid rgb(0,0,255);padding-left:1ex"><br>>>> Victor Olaya <<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>> 07/22/14 12:02 PM >>><br>
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"> <div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div>The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC.</div> <div>After all, what's the point in having tons of features if no-one knows how to use them or what they do?</div>
<div>Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily.<br>
</div></div></div></blockquote><div><br></div><div>-1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. </div>
<div><br></div><div>I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet.</div>
<div><br></div><div>Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible.</div><br></div></div></div>
<font face="Verdana,Arial,Helvetica,Trebuchet MS" size="1"><p> </p></font><p><font face="Verdana,Arial,Helvetica,Trebuchet MS" size="1"> <br></font> </p><font face="Verdana,Arial,Helvetica,Trebuchet MS" size="1">
<br>--
<br>This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
<br>The full disclaimer details can be found at <a href="http://www.csir.co.za/disclaimer.html" target="_blank">http://www.csir.co.za/disclaimer.html</a>.
<p>
<br>This message has been scanned for viruses and dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>,
<br>and is believed to be clean.
</p></font><p><font face="Verdana,Arial,Helvetica,Trebuchet MS" size="1">
<br>Please consider the environment before printing this email.
</font>
</p></blockquote><br><br><br></div><div><div>-- </div><div>Bernd Vogelgesang<br>Siedlerstraße 2<br>91083 Baiersdorf/Igelsdorf<br>Tel: 09133-825374</div></div></div><br>_______________________________________________<br>
Qgis-user mailing list<br>
<a href="mailto:Qgis-user@lists.osgeo.org">Qgis-user@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-user</a><br></blockquote></div><br></div></div></div></div>