On Thu, 1 Nov 2018 at 08:18, Pedro Venâncio wrote:
>
> Hi Nyall,
>
>>
>> > (tools not
>> > working when windows regional settings are not set to English and also
>>
>> Someone else will need to fix this one, it's not something I can
>> reproduce. Any volunteers? If there's none, we shouldn't hold
On Thu, 1 Nov 2018 at 23:08, Jürgen E. Fischer wrote:
>
> Hi,
>
> On Thu, 01. Nov 2018 at 21:47:06 +1000, Nyall Dawson wrote:
> > > I meant 2018-11-02. 2018-11-09 would of course work as well, if there's
> > > more
> > > to fix.
>
> > 2018-11-02 is good for me. I'm working on a fix for
> >
Nyall, thanks for having raised this (and fixed that horrific regression).
Jürgen, thanks for that extra flexibility, much appreciated.
On Thu, Nov 1, 2018, 8:08 PM Jürgen E. Fischer wrote:
> Hi,
>
> On Thu, 01. Nov 2018 at 21:47:06 +1000, Nyall Dawson wrote:
> > > I meant 2018-11-02.
Hi,
On Thu, 01. Nov 2018 at 21:47:06 +1000, Nyall Dawson wrote:
> > I meant 2018-11-02. 2018-11-09 would of course work as well, if there's
> > more
> > to fix.
> 2018-11-02 is good for me. I'm working on a fix for
> https://issues.qgis.org/issues/20312 now which should be ready for
>
On Thu, 1 Nov 2018 at 11:32, Jürgen E. Fischer wrote:
>
> Hi Nyall,
>
> On Thu, 01. Nov 2018 at 08:09:08 +1000, Nyall Dawson wrote:
> > On Wed, 31 Oct 2018 at 21:23, Jürgen E. Fischer wrote:
>
> > > So where are we with fixing the urgent bugs? EPR next friday 12:00 UTC?
>
> > > Next regular PR
Hi Nyall,
On Thu, 01. Nov 2018 at 08:09:08 +1000, Nyall Dawson wrote:
> On Wed, 31 Oct 2018 at 21:23, Jürgen E. Fischer wrote:
> > So where are we with fixing the urgent bugs? EPR next friday 12:00 UTC?
> > Next regular PR would be 2018-11-23 12:00:00 UTC
> Thanks Jürgen -- for
Hi Nyall,
> > (tools not
> > working when windows regional settings are not set to English and also
>
> Someone else will need to fix this one, it's not something I can
> reproduce. Any volunteers? If there's none, we shouldn't hold back a
> release for this.
>
On Wed, 31 Oct 2018 at 20:22, Matthias Kuhn wrote:
> But still then there will be issues and most people will only start
> testing the final release and we will run into "unknown issues" and
> "unreported issues" while working on QGIS and fix and push them without
> a big admin overhead. And we
On Wed, 31 Oct 2018 at 21:23, Jürgen E. Fischer wrote:
> So where are we with fixing the urgent bugs? EPR next friday 12:00 UTC?
>
> Next regular PR would be 2018-11-23 12:00:00 UTC
Thanks Jürgen -- for clarification do you mean 2018-11-02 or 2018-11-09?
Nyall
>
>
> Jürgen
>
> --
> Jürgen
On Wed, 31 Oct 2018 at 19:12, Giovanni Manghi wrote:
> there are also two major issues with Processing/GRASS
> not working for any multilayer datasource like gpkg),
Fixed by https://github.com/qgis/QGIS/pull/8393, which also adds unit
tests to this functionality.
> (tools not
> working when
On Wed, 31 Oct 2018 at 20:49, Richard Duivenvoorde wrote:
>
> Anyway, before releasing 3.4.1 please can other check/confirm this one:
> https://issues.qgis.org/issues/20295
Fixed in master (and only an issue on debug enabled builds). Will
backport to 3.4.
Nyall
Hi Jürgen
On 10/31/18 12:14 PM, Jürgen E. Fischer wrote:
> Hi Matthias,
>
> On Wed, 31. Oct 2018 at 11:22:40 +0100, Matthias Kuhn wrote:
>> I like the concept of a "release candidate".
>
>> I think by labeling a package as RC we will encourage people to
>
> I doubt that two letters will be a
Hi all,
Il 10/31/2018 12:14 PM, Jürgen E. Fischer ha scritto:
>
> Sounds like the best option - other options probably end up with the same
> result just with more effort ;)
>
>
IMHO our release procedure is OK, I agree with Juergen.
IMHO it's just a matter of communication. We should make clear
Hi Matthias,
On Wed, 31. Oct 2018 at 11:22:40 +0100, Matthias Kuhn wrote:
> I like the concept of a "release candidate".
> I think by labeling a package as RC we will encourage people to
I doubt that two letters will be a gamechanger.
> Either we call the LTR x.y.0 version a RC (instead of
Hi Giovanni,
On 10/31/18 11:47 AM, Giovanni Manghi wrote:
> Hi Matthias,
>
>>> The problem here is the "known" part: if we had more testers on the
>>> nightlies during the two weeks before the release date, we would
>>> probably have catched some of these regression in time to fix them.
>>
>>
On Wed, Oct 31, 2018 at 11:48 AM Giovanni Manghi
wrote:
> Hi Matthias,
>
> > > The problem here is the "known" part: if we had more testers on the
> > > nightlies during the two weeks before the release date, we would
> > > probably have catched some of these regression in time to fix them.
> >
On 10/31/2018 11:08 AM, Alessandro Pasotti wrote:
> We might want to introduce the concept of release candidate, in order to
> have a stricter code freeze, and give the testers and translators some
> amount of time for testing and translations, during this time only "real"
> bug fixes should be
Hi Matthias,
> > The problem here is the "known" part: if we had more testers on the
> > nightlies during the two weeks before the release date, we would
> > probably have catched some of these regression in time to fix them.
>
> Agreed, the more testing the better.
serious manual/semi-automated
On 10/31/18 11:08 AM, Alessandro Pasotti wrote:
>
>
> On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi
> mailto:giovanni.man...@gmail.com>> wrote:
>
> > This code freeze period will need to be associated with a strict
> definition of "blocker issues" that really need to by adressed
>
On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi
wrote:
> > This code freeze period will need to be associated with a strict
> definition of "blocker issues" that really need to by adressed immediatly.
> This issue here is a great example of a valid blocker.
>
> big fan of the "no known
> This code freeze period will need to be associated with a strict definition
> of "blocker issues" that really need to by adressed immediatly. This issue
> here is a great example of a valid blocker.
big fan of the "no known regressions admitted", at least for LTR releases.
-- G --
> there are also two major issues with Processing/GRASS (tools not
> working when windows regional settings are not set to English and also
> not working for any multilayer datasource like gpkg), this is for many
> a blocker for the process of adopting QGIS 3 LTR over 2.18.
both are regressions
Thanks Nyall for raising this.
This indeed fells like "deja vu" and we need to advertise users that a
fresh new major release will for sure need point releases. We didn't
probably explain well enough that 3.4 is the LTR candidate, but will
definitly be a LTR in january at the end of life of 2.18
Hi Nyall, all,
> Soo could we break the normal cycle and get a point release out
> quickly? (Ideally with a couple of days prenotice so that anyone else
> working on urgent bug fixes could get them in too)
there are also two major issues with Processing/GRASS (tools not
working when windows
I feel that this is a really serious issue that IMHO can justify a point
release
Peter, +1 to a release candidate
Luigi Pirelli
**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
*
Hi,
> Bah... feels like *every* major release someone ends up sending an email
like this...
My opinion this may show a problem with our development cycle setup. In my
previous company, different closed-sourced software, we had so called code
freeze. For example it could be 1-2 weeks before
That's rather unfortunate, but most probably needed. The issue raised,
20262, affects WMS(T), XYZ, WFS, etc. layers.
On top of - and very much due to - the gravity of the bug itself, 3.4 is
flagged as LTR, and it'd be most appropriate to insure that people jumping
onto this new LTR aren't left
Bah... feels like every major release someone ends up sending an email
like this... but in this case, https://issues.qgis.org/issues/20262
has totally destroyed QGIS network based providers with Qt 5.11 and
above.
This is not anyone's fault -- it's an upstream change in the Qt
library which
28 matches
Mail list logo
