I would like to add something else to the discussion, qgis is adding a lot of
new features and enhancements and don't get me wrong I love them, but it
seems bugs are not squashed at the same pace, I get that adding enhancements
and new features is nice and desirable but I would like one release bei
Hey - thanks for the explanation.
Like I said - this is just from my perspective - A user who might know
more than the average user or might be completely delusional (I vote for
delusional). Youcan see what impressions I get from things - right or
wrong.
I think whatever makes the most sense
Hi all,
IMHO, I agree with the idea of having a LTS (maybe once a year) and
intermediate releases for development.
from my working experience, both with public institutions and privates, seems
to be more comfortable not to shift from one version to the other very often;
pretty appreciated is hav
Hi Randal,
On Thu, 19. Jun 2014 at 10:29:32 -0400, Randal Hale wrote:
> * 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.
Depends on the ubuntu version you have - and if there are packag
On Thu, Jun 19, 2014 at 04:36:47PM +0200, Luca Manganelli wrote:
> In Qgis 1.8 there was a blocking bug and thus it would require a
> 1.8.1, never released, I think, because for the switch from SVN to
> GIT. This bug was the impossibility to split a feature stored in a
> postgis table, because QGI
On Thu, Jun 19, 2014 at 4:29 PM, Randal Hale
wrote:
> A 5 to 6 month release cycle would be fine for a user (at least for me) if
> there were bugfixes in between.
+1 for me, too.
> In 2.0 there was a problem with spatialite -
> there was no fix until the next release. It seems (if memory serves
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..
I look at QGIS has havin
I think that LTS is kind of a really good idea.
At some extent, it's what Sourcepole is doing with its QGIS enterprise.
If we have enough companies paying for such bugfixes & QA, that would be
easily feasible, but someone should be in charge of handling this.
Then, the cycle is another discuss
Hi Nathan,
On Thu, 19. Jun 2014 at 20:34:00 +1000, Nathan Woodrow wrote:
> > Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows
> > maintainers and they all agree with me - I think they already have don't a
> > good job to automated it a good deal, but it's still not fully autom
Hi,
I also think 4 months is too frequent (users on gis.stackexchange are still
reporting on 2.0 release!), but think anything longer than 6 months may be
too long.
What about this scenario (building upon Nathan's suggestion)?
1) 4 full months of development on master branch (currently is only
Good to hear that there are organizations putting money into QA. Thanks
a lot.
I think there are different categories of users, experimental early
adopters and organizations going for stability at the expense of
waiting longer for new features.
To get the best for both, LTS releases may be a g
>
>
> We users need bug-free software more than a predictable release date. We
> don't need QGIS at an exact specific time. But we cannot accept that
> some features are broken that are key to our work
>
Exactly. There is no point having a release if people can't use it. It
will leave a bad taste
Hey Jurgen,
> 6 month dev (including ~1 month freeze) -> release -> 1 month post release
> > freeze -> release a bug fix release if needed -> move on.
>
> 7 months is not good as that would move the schedule into undesireable
> areas
> (like holidays) over time.
I understand. We could go with 4
>
>
> > 6 month dev (including ~1 month freeze) -> release -> 1 month post
> release
> > freeze -> release a bug fix release if needed -> move on.
>
> 7 months is not good as that would move the schedule into undesireable
> areas
> (like holidays) over time.
I understand. Then why not go with 4
Il 19/06/2014 12:19, Andreas Neumann ha scritto:
> I'd like to add to the discussion that there will be more organizations
> investing in bug-fixing in the future. Yesterday, a Swiss canton told me
> that they will invest 5000 CHF each year in QA/bugfixing in the future.
> I am pretty sure that mo
Hi,
I'd like to add to the discussion that there will be more organizations
investing in bug-fixing in the future. Yesterday, a Swiss canton told me
that they will invest 5000 CHF each year in QA/bugfixing in the future.
I am pretty sure that more organizations will follow.
This means that more d
Hi Nathan,
On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote:
> I'm not sure I really like the "just make new releases and avoid bug fixe
> releases" kind of thinking. There are some places that can't roll out a
> whole new release due to possible bugs from major new features, and give
I just want to clarify one thing about this discussion: we are not speaking
about delaying the 2.4 release, which users are expecting in the next 48
hours, right?
The current state of QGIS master could probably be better, but it's not
worse than 2.2 (of course, that's a perception based on my work
Hi all,
I really think we are going blind here about the bugfix or not bugfix
release ! At present, it depends completely of the package maintainers. For
example:
* Under Windows : no bugfix
* Under Debian : bug-fixed via branch release-2_2
* Ubuntugis-unstable : not bugfxied
* opensuze : bugfixe
On Thu, Jun 19, 2014 at 07:32:17PM +1000, Nathan Woodrow wrote:
> I think the main thing is keeping the bug fix patches small so you don't
> affect to much code and is easier to spot where there might be issues.
Agreed. When I spot a bug during development I often first fix it in the
stable branc
I'm not sure I really like the "just make new releases and avoid bug fixe
releases" kind of thinking. There are some places that can't roll out a
whole new release due to possible bugs from major new features, and given
how fast we move this can cause some real issues.
We don't even have to bug f
Hi Andreas,
On Thu, 19. Jun 2014 at 06:34:17 +, Andreas Neumann wrote:
> I would propose to try a six month release cycle with two months feature
> freeze for testing (see also my previous mail about a request for more time
> for testing/bug fixing). Even a yearly release cycle would be fine,
On Thu, Jun 19, 2014 at 11:00:45AM +0200, Paolo Cavallini wrote:
> Il 19/06/2014 10:51, Nathan Woodrow ha scritto:
> > I'm going to learn more towards a longer dev cycle. 4 months open, 2 month
> > feature
> > freeze.
>
> we had that long ago, and it didn't work well.
>
> > Of course I'm also
Il 19/06/2014 10:51, Nathan Woodrow ha scritto:
> I'm going to learn more towards a longer dev cycle. 4 months open, 2 month
> feature
> freeze.
we had that long ago, and it didn't work well.
> Of course I'm also pro stable release but there is less need if you have more
> time to
> fix bugs
I'm going to learn more towards a longer dev cycle. 4 months open, 2 month
feature freeze.
Of course I'm also pro stable release but there is less need if you have
more time to fix bugs.
- Nathan
On Thu, Jun 19, 2014 at 6:37 PM, Paolo Cavallini
wrote:
> Il 19/06/2014 10:32, Régis Haubourg ha
Il 19/06/2014 10:32, Régis Haubourg ha scritto:
> Alex, big corps are real people, trying to do their best to test qgis
Hi all.
I acknowledge the problem, and I understand well its implications. I think a
proper
solution is not having longer release cycles (we had them before, without major
impr
Hi,
again +1 with Andreas.
Alex, big corps are real people, trying to do their best to test qgis like
every other community member, and also having to do support, training,
packaging, deploying inside their corp. We often do not have teams of plenty
members on QGIS. Skipping a version for user de
On 06/18/2014 11:34 PM, Andreas Neumann wrote:
> Hi,
>
> At the Swiss QGIS user meeting yesterday there were some discussions
> whether people can cope with the 4 month release schedule and there were
> a number of users who said that this way too fast for them. By the time
> they could properly t
Hi,
At the Swiss QGIS user meeting yesterday there were some discussions
whether people can cope with the 4 month release schedule and there were
a number of users who said that this way too fast for them. By the time
they could properly test a release, the next release is already there.
Bigger o
29 matches
Mail list logo