Re: [QGIS-Developer] Some thought on LTR

[Alessandro Pasotti]

On Wed, Oct 2, 2019 at 12:22 PM Even Rouault 
wrote:

> > And at this stage in the life of the LTR I just
> > don't see the risks of regressions outweighing anything but
> > crash/corruption fixes.
>
> "Stage" is the keyword here. Number of software vendors have generally
> several
> stages during the lifetime of the product they support, generally a first
> one
> which is the polishing of the release where they can even add new
> features,
> another one where they only backport (critical) bug fixes, and a final one
> where they only backport security related bug fixes.
>
> So, maybe we could have a 2 phase process:
> - First 6 months: backport of bug fixes with the same criteria as we do
> currently
> - Last 6 months: only critical bug fixes (crashes, data loss)
>
> (or 9 months / 3 months, whatever...)
>
>
This looks a good approach to me.



> But if we're really in that mode, that should not only apply to QGIS but
> to
> its dependent libraries as well. Basically this would mean that for
> OSGeo4W,
> you should have 2 distinct sets for the dependencies: one frozen (or with
> very
> controlled changes) for the LTR, and a living one for the new versions.
>
> Even
>

Yes, that makes sense too.


-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Even Rouault]

> And at this stage in the life of the LTR I just
> don't see the risks of regressions outweighing anything but
> crash/corruption fixes.

"Stage" is the keyword here. Number of software vendors have generally several 
stages during the lifetime of the product they support, generally a first one 
which is the polishing of the release where they can even add new features, 
another one where they only backport (critical) bug fixes, and a final one 
where they only backport security related bug fixes.

So, maybe we could have a 2 phase process:
- First 6 months: backport of bug fixes with the same criteria as we do 
currently
- Last 6 months: only critical bug fixes (crashes, data loss)

(or 9 months / 3 months, whatever...)

But if we're really in that mode, that should not only apply to QGIS but to 
its dependent libraries as well. Basically this would mean that for OSGeo4W, 
you should have 2 distinct sets for the dependencies: one frozen (or with very 
controlled changes) for the LTR, and a living one for the new versions.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Wed, 2 Oct 2019 at 15:58, Alessandro Pasotti  wrote:
>
>
> Hi,
>
> was this thread the more recent discussion/decision about what to backport in 
> LTS?
>
> If I understand correctly, the judgment is left to the individual core 
> developer who by chance happens to approve the backport PR.

Correct.

> I'm asking because I feel that we developers do not always agree about what 
> to backport and what not, IMO if the backport
> 1. is a bugfix
> 2. it has a low risk [1] of side effects
> I don't see a valid reason for not doing the backport while I see a few 
> advantages for the LTS users if the bugfix landed into LTS.
>
> In other word, and more importantly: do we have a strict policy that states 
> that "ONLY PATCHES THAT FIX CRASHES OR DATA LOSS ARE ADMISSIBLE FOR 
> BACKPORTING TO LTS"?

No. BUT recently I've been pushing this view hard. I'm of the
firm belief that EVERY backport, regardless how trivial it appears,
brings with it risk. And at this stage in the life of the LTR I just
don't see the risks of regressions outweighing anything but
crash/corruption fixes.

To use an example, take https://github.com/qgis/QGIS/pull/32068
"Disappearing Null representation in Range Widget on
QgsDoubleSpinBox". Tests aside, it's a one line, trival fix. But at
the same time, given the age of 3.4, users are well and truely used to
the current behavior (even if it's not ideal) and have learnt to live
with it. And if that 1 line change causes an unintended regression in
say... entering values in a spin box on non-english locales on
macos... the the consequence is disastrous.

So it's not a matter of just looking at the fix in isolation. It's a
risk management game of weighing up the (ever present) risk of
regression vs the severity of the original bug.

> If this is the case, I would recommend that we write it down in the 
> developers docs and we start to label/close the LTS issues with "WON'T FIX"

Possibly, but it's very different early in the life of the LTR
release. It's only when we close in on the final rounds of patches for
a mature LTR release that I think the pace of chances should slow to a
trickle.

Nyall

> Final note: I really don't have a strong opinion here, but I thinks it's a 
> shame if we waste developer's time on backports that are not admissible and I 
> think we should have a clear(er) policy (unless it's just for me that it's 
> not clear).
>
> Thank you for your opinions!
>
> [1] Yes, I know it's fuzzy but you get the point, examples are: good test 
> coverage, UI only insulated change etc.
>
>
> On Fri, Aug 16, 2019 at 10:00 AM Paolo Cavallini  
> wrote:
>>
>> H
>> i all,
>>
>> On 07/08/19 12:05, Marco Bernasocchi wrote:
>>
>> > - there is a sort of "regression obsession", IMO bugs are bugs, and they
>> > should ideally be fixed whenever possible (also see Jürgen's answer on
>> > another tread [1])
>>
>> I agree 50% here. Of course obsessions are bad. However, breaking an
>> existing functionality scares people away from upgrading, and undermines
>> the credibility of the project. Having people using older version has
>> always been an issue for the project.
>>
>> > - assessing a "low chance of regression" is a gray area and as Nyall
>> > said before "...every bug fix, regardless of how trivial it seems,
>> > brings with it the increased chances of regressions into the stable LTR
>> > release..."
>>
>> fully agreed, this is obviously the main problem here.
>>
>> > - on the economical point of view,  limiting the bugs that can be fixed
>> > in an LTR will make it very difficult to actually get larger users to
>> > pay for bug-fixing, they are the target group for the LTR and slowly
>> > they are understanding that fixing bugs needs resources. To me limiting
>> > the amount of bugs that can be fixed in an LTR would be a very unwise
>> > move since it would also reduce the number of bugs that get fixed in non
>> > LTR releases.
>>
>> this is also a good point. of course clearcut solutions are impossible,
>> so I think it's just a matter of personal judgment. The only practical
>> alternative I see is the one below.
>>
>> >>  I don't see a way to decide other than relying on the
>> >> developer's assessment. The only (costly) improvement I'd see is having
>> >> another independent core dev to check any bugfix before accepting it.
>>
>> All the best.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS.ORG Chair:
>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: 

Re: [QGIS-Developer] Some thought on LTR

[Alessandro Pasotti]

Hi,

was this thread the more recent discussion/decision about what to backport
in LTS?

If I understand correctly, the judgment is left to the individual core
developer who by chance happens to approve the backport PR.

I'm asking because I feel that we developers do not always agree about what
to backport and what not, IMO if the backport
1. is a bugfix
2. it has a low risk [1] of side effects
I don't see a valid reason for not doing the backport while I see a few
advantages for the LTS users if the bugfix landed into LTS.

In other word, and more importantly: do we have a strict policy that states
that "ONLY PATCHES THAT FIX CRASHES OR DATA LOSS ARE ADMISSIBLE FOR
BACKPORTING TO LTS"?

If this is the case, I would recommend that we write it down in the
developers docs and we start to label/close the LTS issues with "WON'T FIX"

Final note: I really don't have a strong opinion here, but I thinks it's a
shame if we waste developer's time on backports that are not admissible and
I think we should have a clear(er) policy (unless it's just for me that
it's not clear).

Thank you for your opinions!

[1] Yes, I know it's fuzzy but you get the point, examples are: good test
coverage, UI only insulated change etc.


On Fri, Aug 16, 2019 at 10:00 AM Paolo Cavallini 
wrote:

> H
> i all,
>
> On 07/08/19 12:05, Marco Bernasocchi wrote:
>
> > - there is a sort of "regression obsession", IMO bugs are bugs, and they
> > should ideally be fixed whenever possible (also see Jürgen's answer on
> > another tread [1])
>
> I agree 50% here. Of course obsessions are bad. However, breaking an
> existing functionality scares people away from upgrading, and undermines
> the credibility of the project. Having people using older version has
> always been an issue for the project.
>
> > - assessing a "low chance of regression" is a gray area and as Nyall
> > said before "...every bug fix, regardless of how trivial it seems,
> > brings with it the increased chances of regressions into the stable LTR
> > release..."
>
> fully agreed, this is obviously the main problem here.
>
> > - on the economical point of view,  limiting the bugs that can be fixed
> > in an LTR will make it very difficult to actually get larger users to
> > pay for bug-fixing, they are the target group for the LTR and slowly
> > they are understanding that fixing bugs needs resources. To me limiting
> > the amount of bugs that can be fixed in an LTR would be a very unwise
> > move since it would also reduce the number of bugs that get fixed in non
> > LTR releases.
>
> this is also a good point. of course clearcut solutions are impossible,
> so I think it's just a matter of personal judgment. The only practical
> alternative I see is the one below.
>
> >>  I don't see a way to decide other than relying on the
> >> developer's assessment. The only (costly) improvement I'd see is having
> >> another independent core dev to check any bugfix before accepting it.
>
> All the best.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Paolo Cavallini]

H
i all,

On 07/08/19 12:05, Marco Bernasocchi wrote:

> - there is a sort of "regression obsession", IMO bugs are bugs, and they
> should ideally be fixed whenever possible (also see Jürgen's answer on
> another tread [1])

I agree 50% here. Of course obsessions are bad. However, breaking an
existing functionality scares people away from upgrading, and undermines
the credibility of the project. Having people using older version has
always been an issue for the project.

> - assessing a "low chance of regression" is a gray area and as Nyall
> said before "...every bug fix, regardless of how trivial it seems,
> brings with it the increased chances of regressions into the stable LTR
> release..."

fully agreed, this is obviously the main problem here.

> - on the economical point of view,  limiting the bugs that can be fixed
> in an LTR will make it very difficult to actually get larger users to
> pay for bug-fixing, they are the target group for the LTR and slowly
> they are understanding that fixing bugs needs resources. To me limiting
> the amount of bugs that can be fixed in an LTR would be a very unwise
> move since it would also reduce the number of bugs that get fixed in non
> LTR releases.

this is also a good point. of course clearcut solutions are impossible,
so I think it's just a matter of personal judgment. The only practical
alternative I see is the one below.

>>  I don't see a way to decide other than relying on the
>> developer's assessment. The only (costly) improvement I'd see is having
>> another independent core dev to check any bugfix before accepting it.

All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Marco Bernasocchi]

Hi all

On 05.08.19 18:05, Paolo Cavallini wrote:
> Hiii all,
>
> On 05/08/19 11:10, Matthias Kuhn wrote:
>> On 8/5/19 1:00 AM, Nyall Dawson wrote:
>>> On Fri, 2 Aug 2019 at 18:13, Matthias Kuhn  wrote:
>>>
     d) Stop shipping bugfixes (hint: joke, that makes the LTR concept
 pointless and anyone can do that today already by sticking to the .0
 patch release ;) )
>>> Actually - jokes aside - this does raise a good question.
>>>
>>> We've never (as far as i know) formally defined about what the goal of
>>> the LTR is. Is it:
>>> 1. a version of QGIS with every bug fix possible backported
>>> or
>>> 2. a version of QGIS with only absolutely critical bugfixes
>>> backported, such as security risks or data corruption bugs
>> That's a very good question.
> thanks, very important indeed. I assumed we decide for 1.
> In fact, experience showed that it is preferable to be more
> conservative, and only include fixes with very low chances of
> regressions.

I see two "technical" and one economical issues here.

- there is a sort of "regression obsession", IMO bugs are bugs, and they
should ideally be fixed whenever possible (also see Jürgen's answer on
another tread [1])

- assessing a "low chance of regression" is a gray area and as Nyall
said before "...every bug fix, regardless of how trivial it seems,
brings with it the increased chances of regressions into the stable LTR
release..."

- on the economical point of view,  limiting the bugs that can be fixed
in an LTR will make it very difficult to actually get larger users to
pay for bug-fixing, they are the target group for the LTR and slowly
they are understanding that fixing bugs needs resources. To me limiting
the amount of bugs that can be fixed in an LTR would be a very unwise
move since it would also reduce the number of bugs that get fixed in non
LTR releases.


>  I don't see a way to decide other than relying on the
> developer's assessment. The only (costly) improvement I'd see is having
> another independent core dev to check any bugfix before accepting it.
> Cheers.

Cheers

Marco


[1] https://lists.osgeo.org/pipermail/qgis-psc/2019-August/007525.html
-- 
Marco Bernasocchi
OPENGIS.ch CEO
QGIS.org Co-chair
ma...@opengis.ch 
+41 (0)79 467 24 70 

OPENGIS.ch Logo 
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Paolo Cavallini]

Hiii all,

On 05/08/19 11:10, Matthias Kuhn wrote:
> On 8/5/19 1:00 AM, Nyall Dawson wrote:
>> On Fri, 2 Aug 2019 at 18:13, Matthias Kuhn  wrote:
>>
>>>     d) Stop shipping bugfixes (hint: joke, that makes the LTR concept
>>> pointless and anyone can do that today already by sticking to the .0
>>> patch release ;) )
>> Actually - jokes aside - this does raise a good question.
>>
>> We've never (as far as i know) formally defined about what the goal of
>> the LTR is. Is it:
>> 1. a version of QGIS with every bug fix possible backported
>> or
>> 2. a version of QGIS with only absolutely critical bugfixes
>> backported, such as security risks or data corruption bugs
> 
> That's a very good question.

thanks, very important indeed. I assumed we decide for 1.
In fact, experience showed that it is preferable to be more
conservative, and only include fixes with very low chances of
regressions. I don't see a way to decide other than relying on the
developer's assessment. The only (costly) improvement I'd see is having
another independent core dev to check any bugfix before accepting it.
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Matthias Kuhn]

On 8/5/19 1:00 AM, Nyall Dawson wrote:

On Fri, 2 Aug 2019 at 18:13, Matthias Kuhn  wrote:


d) Stop shipping bugfixes (hint: joke, that makes the LTR concept
pointless and anyone can do that today already by sticking to the .0
patch release ;) )

Actually - jokes aside - this does raise a good question.

We've never (as far as i know) formally defined about what the goal of
the LTR is. Is it:
1. a version of QGIS with every bug fix possible backported
or
2. a version of QGIS with only absolutely critical bugfixes
backported, such as security risks or data corruption bugs


That's a very good question.

While there's no binary crystal clear categorization possible anyway, I 
realize that we tend toward 1. if it's a fixes affecting 
(experienced/sponsored/implemented by) ourselves and 2. for any other 
fix. Which introduces a bias that can cause tension.


So I agree that:

IF the concerns with the current (1.) approach are too high, the 
decision for 2. is better taken as a community and made official so it 
can be communicated easier to our clients and users.


(And then even with the decision taken, the situation will be tricky. At 
the time a client reports a bug and funding is available, it almost 
always looks like a trivial fix and it's easy to promise a backport 
"what could potentially go wrong?". Whereas the question about the 
categorization of a bugfix mostly appears in retrospective when it turns 
out something has gone wrong and the situation is already difficult.)


Matthias


(or somewhere between the two)

Currently, it's very much 1. We see everything backported from crash
fixes to string updates to performance optimisations to backported
API. Maybe this is the problem. Maybe we should only be accepting
absolutely mission critical bug fixes, and the expectation is to see
only 1 or 2 commits between LTR patch release versions. Reality is
that every bug fix, regardless of how trivial it seems, brings with it
the increased chances of regressions into the stable LTR release...

Possibly this is a question we need to raise with our voting panel or
user communities, in order to work out exactly what people's desires
from the LTR are.

Nyall

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Fri, 2 Aug 2019 at 18:13, Matthias Kuhn  wrote:

>d) Stop shipping bugfixes (hint: joke, that makes the LTR concept
> pointless and anyone can do that today already by sticking to the .0
> patch release ;) )

Actually - jokes aside - this does raise a good question.

We've never (as far as i know) formally defined about what the goal of
the LTR is. Is it:
1. a version of QGIS with every bug fix possible backported
or
2. a version of QGIS with only absolutely critical bugfixes
backported, such as security risks or data corruption bugs

(or somewhere between the two)

Currently, it's very much 1. We see everything backported from crash
fixes to string updates to performance optimisations to backported
API. Maybe this is the problem. Maybe we should only be accepting
absolutely mission critical bug fixes, and the expectation is to see
only 1 or 2 commits between LTR patch release versions. Reality is
that every bug fix, regardless of how trivial it seems, brings with it
the increased chances of regressions into the stable LTR release...

Possibly this is a question we need to raise with our voting panel or
user communities, in order to work out exactly what people's desires
from the LTR are.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[matteo]

Hi Matthias,

> One the first principles of every of our developers is to try to avoid
> regressions. Whenever a QGIS developer writes code or reviews code,
> there is this process in the back of the head going on thinking "could
> this cause side effects?". Most of the times we are quite efficient in
> detecting side effects and if in doubt running some tests (manually or
> by adding unit tests) to check and adjust if required. This is what
> makes QGIS a rock solid piece of software (are you in doubt? Take QGIS
> 2.0 and QGIS 3.4 and perform some common GIS tasks). It's pretty awesome
> actually!

a good comparison is also Processing frawoek in 2.x and 3.x, steps made
are impressive.

> At the same time, let's not obstruct our view too much by outliers. In
> my opinion we are doing very well with what we have available and are
> overall heading in a good direction!

yes we are doing well QGIS :) I just would have raised a topic but I
understand that it is super easy to such a delicate topic to be
misinterpreted.
> 
> Let's rock on and make QGIS even better

:)

Matteo

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Mathieu Pellerin]

Matthias, you're raising a good point on the 2.0 vs 3.4 (I'd argue 2.18 vs
3.4 too). Sometimes we tend to get so "passionate" about specific bugs that
impact our own workflows that we end up not seeing the forest for the
trees. 3.4 LTS is overall a much, much more solid product than 2.18 was and
our ever growing number of test cases insure this positive trend can be
maintained.



On Fri, Aug 2, 2019 at 3:13 PM Matthias Kuhn  wrote:

> Hello list,
>
> Some more thoughts on this topic, because it comes up repeatedly.
>
> One the first principles of every of our developers is to try to avoid
> regressions. Whenever a QGIS developer writes code or reviews code,
> there is this process in the back of the head going on thinking "could
> this cause side effects?". Most of the times we are quite efficient in
> detecting side effects and if in doubt running some tests (manually or
> by adding unit tests) to check and adjust if required. This is what
> makes QGIS a rock solid piece of software (are you in doubt? Take QGIS
> 2.0 and QGIS 3.4 and perform some common GIS tasks). It's pretty awesome
> actually!
>
> Once in a while though, this process fails to detect a risk or
> implication or use case of which "the developer" was not aware [1].
> Unfortunately we are not able to completely avoid this situation.
>
> We could of course
>
>a) Throw more review power to it. If we have the resources to
> download, build and run every pull request, that will help to catch some
> additional issues.
>
>b) Perform more real world testing. The more testing is done on
> nightly builds, the quicker the turnaround to detect issues.
>
>c) Combined with b) have more continuous developer power for
> bugfixing (not only before a release)
>
>d) Stop shipping bugfixes (hint: joke, that makes the LTR concept
> pointless and anyone can do that today already by sticking to the .0
> patch release ;) )
>
>
> As you also, Matteo, I am not able to offer a solution (unfortunately).
> So this is mostly food for thoughts.
>
> Any initiative or strategic decisions to improve a), b) and c) is very
> welcome.
>
>
> At the same time, let's not obstruct our view too much by outliers. In
> my opinion we are doing very well with what we have available and are
> overall heading in a good direction!
>
>
> Let's rock on and make QGIS even better
>
> Matthias
>
>
> [1] A slight exaggeration, but nice illustration nevertheless
> https://xkcd.com/1172/
>
>
> On 8/2/19 8:46 AM, Matthias Kuhn wrote:
> > Hi Matteo
> >
> > On 8/2/19 7:15 AM, matteo wrote:
> >> Hi,
> >>
> >>> Right -- but again, I see no concrete issues here. We have one issue
> >>> which isn't a regression (postgis rasters) and is instead a feature
> >>> request, and one regression which was caused by an important fix
> >>> (broken grass for Windows non-English users), not a feature! (And one
> >>> unknown issue cos you pasted the wrong link ;)
> >> just to finish the thread:
> >>
> >> https://github.com/qgis/QGIS/issues/30787
> >
> > Same situation as with grass here:
> >
> > - A first issue was reported
> >
> > - The fix for the first issue had unintended and unlucky side effects
> > (a risk that comes with every bugfix/change unfortunately)
> >
> > - Followup problem was reported
> >
> > - Patch was supplied within some days after reporting the regression
> >
> > Matthias
> >
> >>
> >>> Also - just to point out - Alessandro implemented the feature request
> >>> overnight. Big kudos to him -- we finally have a stable way of using
> >>> PostGIS rasters in QGIS.*
> >> kudos to Alessandro and thanks for sharing your thoughts
> >>
> >> Matteo
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Matthias Kuhn]

Hello list,

Some more thoughts on this topic, because it comes up repeatedly.

One the first principles of every of our developers is to try to avoid 
regressions. Whenever a QGIS developer writes code or reviews code, 
there is this process in the back of the head going on thinking "could 
this cause side effects?". Most of the times we are quite efficient in 
detecting side effects and if in doubt running some tests (manually or 
by adding unit tests) to check and adjust if required. This is what 
makes QGIS a rock solid piece of software (are you in doubt? Take QGIS 
2.0 and QGIS 3.4 and perform some common GIS tasks). It's pretty awesome 
actually!


Once in a while though, this process fails to detect a risk or 
implication or use case of which "the developer" was not aware [1]. 
Unfortunately we are not able to completely avoid this situation.


We could of course

  a) Throw more review power to it. If we have the resources to 
download, build and run every pull request, that will help to catch some 
additional issues.


  b) Perform more real world testing. The more testing is done on 
nightly builds, the quicker the turnaround to detect issues.


  c) Combined with b) have more continuous developer power for 
bugfixing (not only before a release)


  d) Stop shipping bugfixes (hint: joke, that makes the LTR concept 
pointless and anyone can do that today already by sticking to the .0 
patch release ;) )



As you also, Matteo, I am not able to offer a solution (unfortunately). 
So this is mostly food for thoughts.


Any initiative or strategic decisions to improve a), b) and c) is very 
welcome.



At the same time, let's not obstruct our view too much by outliers. In 
my opinion we are doing very well with what we have available and are 
overall heading in a good direction!



Let's rock on and make QGIS even better

Matthias


[1] A slight exaggeration, but nice illustration nevertheless 
https://xkcd.com/1172/



On 8/2/19 8:46 AM, Matthias Kuhn wrote:

Hi Matteo

On 8/2/19 7:15 AM, matteo wrote:

Hi,


Right -- but again, I see no concrete issues here. We have one issue
which isn't a regression (postgis rasters) and is instead a feature
request, and one regression which was caused by an important fix
(broken grass for Windows non-English users), not a feature! (And one
unknown issue cos you pasted the wrong link ;)

just to finish the thread:

https://github.com/qgis/QGIS/issues/30787


Same situation as with grass here:

- A first issue was reported

- The fix for the first issue had unintended and unlucky side effects 
(a risk that comes with every bugfix/change unfortunately)


- Followup problem was reported

- Patch was supplied within some days after reporting the regression

Matthias




Also - just to point out - Alessandro implemented the feature request
overnight. Big kudos to him -- we finally have a stable way of using
PostGIS rasters in QGIS.*

kudos to Alessandro and thanks for sharing your thoughts

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Tim Sutton]

Hi

Wow yay! Thanks so much for the PG raster support Alessandro! Cant wait to
try it out!

Regards

Tim


> Also - just to point out - Alessandro implemented the feature request
> overnight. Big kudos to him -- we finally have a stable way of using
> PostGIS rasters in QGIS.*
>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Matthias Kuhn]

Hi Matteo

On 8/2/19 7:15 AM, matteo wrote:

Hi,


Right -- but again, I see no concrete issues here. We have one issue
which isn't a regression (postgis rasters) and is instead a feature
request, and one regression which was caused by an important fix
(broken grass for Windows non-English users), not a feature! (And one
unknown issue cos you pasted the wrong link ;)

just to finish the thread:

https://github.com/qgis/QGIS/issues/30787


Same situation as with grass here:

- A first issue was reported

- The fix for the first issue had unintended and unlucky side effects (a 
risk that comes with every bugfix/change unfortunately)


- Followup problem was reported

- Patch was supplied within some days after reporting the regression

Matthias




Also - just to point out - Alessandro implemented the feature request
overnight. Big kudos to him -- we finally have a stable way of using
PostGIS rasters in QGIS.*

kudos to Alessandro and thanks for sharing your thoughts

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[matteo]

Hi,

> Right -- but again, I see no concrete issues here. We have one issue
> which isn't a regression (postgis rasters) and is instead a feature
> request, and one regression which was caused by an important fix
> (broken grass for Windows non-English users), not a feature! (And one
> unknown issue cos you pasted the wrong link ;)

just to finish the thread:

https://github.com/qgis/QGIS/issues/30787

> Also - just to point out - Alessandro implemented the feature request
> overnight. Big kudos to him -- we finally have a stable way of using
> PostGIS rasters in QGIS.*

kudos to Alessandro and thanks for sharing your thoughts

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Fri, 2 Aug 2019 at 00:17, matteo  wrote:
>
> Hi Nyall,
>
> > I'm not saying that we DON'T have some bad regressions which slip in
> > occasionally to the LTR (the recent db manager regression discussion
> > comes to mind), but I honestly don't think there's a bigger problem
> > here. Everything listed here (GRASS provider, PostGIS rasters, db
> > manager edge cases) have always had a shaky past in QGIS, and
> > regressions to them are (and ALWAYS have been) common. So I don't
> > think the issue lies in the LTR or the handling of it, rather the
> > issue lies in the code and lack of stability in these parts of QGIS.
> > (Mathieu - might be time for your thread on one of these points...
> > hint hint!)
>
> just to dissolve doubts: the work and efforts in bug fixing (LTR and not
> LTR) is awesome. Kudos to QGIS and every one that provides financial
> support on this and kudos to all the devs.
>
> Let me just try to explain it better.
>
> From an user point of view having tons of new feature every 4 months is
> incredible: it makes the user happy, more curious and conscious that the
> QGIS community is very active.
>
> From another user point of view having some daily tools broken in the
> LTR release makes me think on the global efforts in the QGIS community:
> I have then to downgrade to another version or wait for the fix (even if
> users should not wait but be part of the community, but that's another
> thing). And maybe as user I would prefer to have the "same" tools but in
> a safer way (software cannot be bugless of course.

Right -- but again, I see no concrete issues here. We have one issue
which isn't a regression (postgis rasters) and is instead a feature
request, and one regression which was caused by an important fix
(broken grass for Windows non-English users), not a feature! (And one
unknown issue cos you pasted the wrong link ;)

Also - just to point out - Alessandro implemented the feature request
overnight. Big kudos to him -- we finally have a stable way of using
PostGIS rasters in QGIS.*

Nyall

* Ironically enough, this is a feature.



>
> Of course bugfixing is not fun for nobody and making new stuff is 1
> times better.
>
> So just to be even more clear: I don't have a proposal (ping @Tim ;) )
> and I think the bug situation is not bad at all (regression or not
> regression) and really think the efforts and work behind the scenes is
> incredible.
>
> Just my 2 cents (after an unlucky workflow where I hit different bugs).
>
> Cheers and thanks
>
> Matteo
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Tim Sutton]

Hi


> On 1 Aug 2019, at 15:04, matteo  wrote:
> 
> Hi Tim,
> 
>>> I'm not writing this email because I have a proposal, 
>> 
>> In addition to Nyall’s reply, can I ask what the actual proposal you
>> have is? Hint: proposals like ‘I would like to donate 10 million USD to
>> support LTRs and fix every known bug’ would be warmly accepted. But
>> seriously if you have a good proposal to improve things of course we
>> would love to hear it.
>> 
> 
> ouch, Italian versus English and double negations mess :)
> 
> AKA: I don't have a proposal, just writing my thoughts

Ah ok thanks for the clarification! I also misread your sentence which didn’t 
help :-P

Regards

Tim


> 
> Matteo

—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[matteo]

Hi Nyall,

> I'm not saying that we DON'T have some bad regressions which slip in
> occasionally to the LTR (the recent db manager regression discussion
> comes to mind), but I honestly don't think there's a bigger problem
> here. Everything listed here (GRASS provider, PostGIS rasters, db
> manager edge cases) have always had a shaky past in QGIS, and
> regressions to them are (and ALWAYS have been) common. So I don't
> think the issue lies in the LTR or the handling of it, rather the
> issue lies in the code and lack of stability in these parts of QGIS.
> (Mathieu - might be time for your thread on one of these points...
> hint hint!)

just to dissolve doubts: the work and efforts in bug fixing (LTR and not
LTR) is awesome. Kudos to QGIS and every one that provides financial
support on this and kudos to all the devs.

Let me just try to explain it better.

From an user point of view having tons of new feature every 4 months is
incredible: it makes the user happy, more curious and conscious that the
QGIS community is very active.

From another user point of view having some daily tools broken in the
LTR release makes me think on the global efforts in the QGIS community:
I have then to downgrade to another version or wait for the fix (even if
users should not wait but be part of the community, but that's another
thing). And maybe as user I would prefer to have the "same" tools but in
a safer way (software cannot be bugless of course.

Of course bugfixing is not fun for nobody and making new stuff is 1
times better.

So just to be even more clear: I don't have a proposal (ping @Tim ;) )
and I think the bug situation is not bad at all (regression or not
regression) and really think the efforts and work behind the scenes is
incredible.

Just my 2 cents (after an unlucky workflow where I hit different bugs).

Cheers and thanks

Matteo

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[matteo]

Hi Tim,

>> I'm not writing this email because I have a proposal, 
> 
> In addition to Nyall’s reply, can I ask what the actual proposal you
> have is? Hint: proposals like ‘I would like to donate 10 million USD to
> support LTRs and fix every known bug’ would be warmly accepted. But
> seriously if you have a good proposal to improve things of course we
> would love to hear it.
>

ouch, Italian versus English and double negations mess :)

AKA: I don't have a proposal, just writing my thoughts

Matteo
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Tim Sutton]

Hi

> I'm not writing this email because I have a proposal, 

In addition to Nyall’s reply, can I ask what the actual proposal you have is? 
Hint: proposals like ‘I would like to donate 10 million USD to support LTRs and 
fix every known bug’ would be warmly accepted. But seriously if you have a good 
proposal to improve things of course we would love to hear it.

Regards

Tim
—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Wed, 31 Jul 2019 at 23:16, matteo  wrote:
>
> Hi devs,
>
> I just discovered a serious bug in LTR on a Ubuntu 16.04 machine (on
> 16.04 QGIS 3.4 is the most updated version an user can have). Same issue
> as listed here [0].

Is your link to [0] incorrect? It's the same as [1], which was
resolved very quickly after identification...

> some big regressions ([1], [2]...)

...and honestly, I don't think [1] was a huge regression. It resulted
from a fix for GRASS handling on Windows with non-ascii paths, and
only affected Ubuntu 16.04 users. The number of users affected by the
original issue would be much, MUCH greater than the number of Ubuntu
16.04 users of GRASS algorithms. And a fix was pushed almost
immediately after the bug was reported, so to me this one is just bad
luck, and not symptomatic of problems in our development processes.
(The only "fix" I could see as possible here would be to add Ubuntu
16.04 as a platform on which our CI tests are run, but to do that we'd
need to pay and upgrade from the free Travis account we currently use
and get access to unlimited parallel builds. We're already struggling
with the limitations in parallel builds on the free account with just
one build target).

> [2]

I don't see any evidence that [2] is a regression and not a feature
request, as I'm of the impression this has never been supported by the
inbuilt browser. In fact, it's only recently that QGIS browser backend
would be able to support this kind of mixed-provider structure (i.e.
postgis provider node which shows layers which must be loaded via
gdal), (and I'm only 50-50 that it would be possible currently without
further API work).

Sounds like a good goal though, and would be a great followup to
Alessandro's upcoming dbmanager -> browser work. I'm personally of the
impression that Postgis raster's have never been a first class citizen
in QGIS, and have only ever worked
kind-of-sort-of-if-you-hold-your-breathe-right. It would be great to
see this remedied and them become fully supported via browser and the
data source manager, and covered by unit tests so that we CAN safely
rely on accessing them in QGIS.

> I'm not writing this email because I have a proposal, I'm just curious
> if someone else feels the same: of course it is normal to have bug (and
> regressions) but I really think we should think to enhance a little bit
> more the LTR...

I'm not saying that we DON'T have some bad regressions which slip in
occasionally to the LTR (the recent db manager regression discussion
comes to mind), but I honestly don't think there's a bigger problem
here. Everything listed here (GRASS provider, PostGIS rasters, db
manager edge cases) have always had a shaky past in QGIS, and
regressions to them are (and ALWAYS have been) common. So I don't
think the issue lies in the LTR or the handling of it, rather the
issue lies in the code and lack of stability in these parts of QGIS.
(Mathieu - might be time for your thread on one of these points...
hint hint!)

Nyall



>
> Cheers and thanks for feedback
>
> Matteo
>
>
> [0]
> http://osgeo-org.1560.x6.nabble.com/Problem-with-PROCESSING-GRASS-Algorithms-td5392185.html
> [1]
> http://osgeo-org.1560.x6.nabble.com/Problem-with-PROCESSING-GRASS-Algorithms-td5392185.html
> [2] https://github.com/qgis/QGIS/issues/30211
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Some thought on LTR

[matteo]

Hi devs,

I just discovered a serious bug in LTR on a Ubuntu 16.04 machine (on
16.04 QGIS 3.4 is the most updated version an user can have). Same issue
as listed here [0].

Besides on this specific issue, I think recent 3.4 LTR suffered from
some big regressions ([1], [2]...): some of them have been fortunately
solved, but still

I'm not writing this email because I have a proposal, I'm just curious
if someone else feels the same: of course it is normal to have bug (and
regressions) but I really think we should think to enhance a little bit
more the LTR...

Cheers and thanks for feedback

Matteo


[0]
http://osgeo-org.1560.x6.nabble.com/Problem-with-PROCESSING-GRASS-Algorithms-td5392185.html
[1]
http://osgeo-org.1560.x6.nabble.com/Problem-with-PROCESSING-GRASS-Algorithms-td5392185.html
[2] https://github.com/qgis/QGIS/issues/30211
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer