<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
If I could chime in as a Non-developer. I might be more of a
non-standard user (given with all the things I'm trying to do with
QGIS). I tried to keep up with all the thoughts in this email chain
- The joys of sleeping in the GMT-5 timeszone (or is it
+)...anyway......<br>
<br>
I look at QGIS has having four operating systems it supports: Linux
(debian and ubuntu because I am familiar with those), mac, windows,
android:<br>
<ul>
<li>The linux releases only seem to get release once with no bug
fixes. Really that depends on the distro though...but for Ubuntu
I think that is correct. <br>
</li>
<li>The windows release (using osgeo) is absolutely great - it
seems to be getting bugfixes all the time. </li>
<li>I've only installed QGIS on a MAC twice - but from what I can
tell it might be getting bugfixes between releases</li>
<li>Android - I have no clue. </li>
</ul>
<br>
Of course I have no clue how long it takes to release - I compiled
QGIS once and that was an all day thing for me (adding libraries and
things). I'm not a developer although I have dreams. <br>
<br>
A 5 to 6 month release cycle would be fine for a user (at least for
me) if there were bugfixes in between. In 2.0 there was a problem
with spatialite - there was no fix until the next release. It seems
(if memory serves me ) there was a fix that rolled out on the OSGEO
side in windows at some point. I went against what I normally do and
have been running 2.3 for production and it's great (at least from
my standpoint). I've tried to respond in with reports and what not.
<br>
<br>
Really I say all of that and I think we (users) are good with
whatever as long as you guys are happy with it. It seems like this
email stirred up some uneasiness among your guys for release. Any
user (in his right mind) isn't sitting there with everything waiting
on 2.4 coming out in 48 hours. You guys are the experts - make
yourselves happy. Happy developers = better QGIS release. <br>
<br>
If I could only add one thing - solidify the releases. Make each one
mimic the other. Make Linux the same as windows the same as Mac.
That's the joy of QGIS - it runs everywhere. Right now I thing the
osgeo windows version (because mostly of sid and ecw support) is the
best version released. I run xubuntu 14.04 on my main workstation
and I think QGIS solid - but QGIS on windows seems to edge that one
out just a bit. Maybe it's because most of the world runs on windows
and mac and there's a few of use linux users out and about. <br>
<br>
Anyway - my 2 cents worth. <br>
<br>
Thank you for the work you are doing. <br>
<br>
Randy<br>
<br>
<span><font color="#888888">-----------------<br>
Randal Hale<br>
North River Geographic Systems, Inc<br>
<a moz-do-not-send="true"
href="http://www.northrivergeographic.com" target="_blank">http://www.northrivergeographic.com</a><br>
<a moz-do-not-send="true" href="tel:423.653.3611"
value="+14236533611" target="_blank">423.653.3611</a> <a
moz-do-not-send="true"
href="mailto:rjhale@northrivergeographic.com" target="_blank">rjhale@northrivergeographic.com</a><br>
twitter:rjhale<br>
<a moz-do-not-send="true" href="http://about.me/rjhale"
target="_blank">http://about.me/rjhale</a></font></span><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 06/19/2014 08:33 AM, Denis Rouzaud
wrote:<br>
</div>
<blockquote cite="mid:53A2D888.8020500@gmail.com" type="cite">I
think that LTS is kind of a really good idea.
<br>
<br>
At some extent, it's what Sourcepole is doing with its QGIS
enterprise.
<br>
If we have enough companies paying for such bugfixes & QA,
that would be easily feasible, but someone should be in charge of
handling this.
<br>
<br>
Then, the cycle is another discussion. It could be either 2 or 3
releases a year, with 1 over 2 or 3 being LTS.
<br>
<br>
But I would definitely investigate the idea of the LTS.
<br>
<br>
Greetings,
<br>
Denis
<br>
<br>
<br>
On 19.06.2014 12:44, Matthias Kuhn wrote:
<br>
<blockquote type="cite">Good to hear that there are organizations
putting money into QA. Thanks
<br>
a lot.
<br>
<br>
I think there are different categories of users, experimental
early
<br>
adopters and organizations going for stability at the expense of
<br>
waiting longer for new features.
<br>
<br>
To get the best for both, LTS releases may be a good option. One
LTS
<br>
branch every 8 or 12 months which gets fixes backported and 1 or
2
<br>
other releases in between which work the way we currently have
it.
<br>
<br>
Advantages are
<br>
New features get tested in the in-between releases (they will
get used
<br>
because they are not called experimental or testing or rc).
<br>
Big organizations use the same LTS release (in comparison to the
<br>
general advice of "take every second release" which will bring
one org
<br>
to use the Jun release and the other one the Feb release) and
can
<br>
collaborate with bugfixing
<br>
Backports of bugfixes have always to be done for one
specific/defined
<br>
version. (In comparison: if a company skips release 2.6 they are
still
<br>
with 2.4 in the 2.7 period, and nobody will backport to 2.4 at
that
<br>
stage)
<br>
<br>
Best,
<br>
Matthias
<br>
<br>
On Don 19 Jun 2014 12:33:01 CEST, Paolo Cavallini wrote:
<br>
<blockquote type="cite">Il 19/06/2014 12:19, Andreas Neumann ha
scritto:
<br>
<br>
<blockquote type="cite">I'd like to add to the discussion that
there will be more organizations
<br>
investing in bug-fixing in the future. Yesterday, a Swiss
canton told me
<br>
that they will invest 5000 CHF each year in QA/bugfixing in
the future.
<br>
I am pretty sure that more organizations will follow.
<br>
</blockquote>
Wonderful, this is the way to go IMHO.
<br>
<br>
<blockquote type="cite">But it is important that we will
provide bug-fix releases and that there
<br>
is a reasonable time available for testing. The short
releases do not
<br>
help at all for organizations - because each new release
introduces more
<br>
and different bugs.
<br>
</blockquote>
The above mentioned resources could be used for maintaining a
stable branch, and
<br>
backporting.
<br>
<br>
<blockquote type="cite">We users need bug-free software more
than a predictable release date. We
<br>
don't need QGIS at an exact specific time. But we cannot
accept that
<br>
some features are broken that are key to our work.
<br>
</blockquote>
Agreed fully: that's what Blocker category is for.
<br>
All the best, and thanks for this important discussion.
<br>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Qgis-developer mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
<br>
</blockquote>
<br>
_______________________________________________
<br>
Qgis-developer mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/qgis-developer">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
<br>
</blockquote>
<br>
</body>
</html>