[QGIS-Developer] Early 3.4 point release?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] Early 3.4 point release?

Nyall Dawson
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 changed some behavior we relied on. Not there fault, not
our fault. But end result is that it makes QGIS basically unusable for
any non gdal/ogr layers on Qt >= 5.11. And unfortunately our major
platforms only saw an upgrade to Qt 5.11 late in the bug fixing
period, which made this one slow to be identified.

https://github.com/qgis/QGIS/pull/8383 should fix it.

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)

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Mathieu Pellerin
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 with a bad first impression.

Math




On Wed, Oct 31, 2018 at 8:55 AM Nyall Dawson <[hidden email]> wrote:
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 changed some behavior we relied on. Not there fault, not
our fault. But end result is that it makes QGIS basically unusable for
any non gdal/ogr layers on Qt >= 5.11. And unfortunately our major
platforms only saw an upgrade to Qt 5.11 late in the bug fixing
period, which made this one slow to be identified.

https://github.com/qgis/QGIS/pull/8383 should fix it.

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)

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Peter Petrik
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 actual release and ideally some users would have time to test the "release-candidate" of QGIS before going public.

From wikipedia:
  • (complete) code freeze, in which no changes whatsoever are permitted to a portion or the entirety of the program's source code. Particularly in large software systems, any change to the source code may have unintended consequences, potentially introducing new bugs; thus, a code freeze helps ensure that a portion of the program that is known to work correctly will continue to do so. Code freezes are often employed in the final stages of development, when a particular release or iteration is being tested, but may also be used to prevent changes to one portion of a program while another is undergoing development.
Cheers,
Peter

On Wed, Oct 31, 2018 at 6:32 AM Mathieu Pellerin <[hidden email]> wrote:
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 with a bad first impression.

Math




On Wed, Oct 31, 2018 at 8:55 AM Nyall Dawson <[hidden email]> wrote:
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 changed some behavior we relied on. Not there fault, not
our fault. But end result is that it makes QGIS basically unusable for
any non gdal/ogr layers on Qt >= 5.11. And unfortunately our major
platforms only saw an upgrade to Qt 5.11 late in the bug fixing
period, which made this one slow to be identified.

https://github.com/qgis/QGIS/pull/8383 should fix it.

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)

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

ginetto
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
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
* https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**************************************************************************************************


On Wed, 31 Oct 2018 at 08:04, Peter Petrik <[hidden email]> wrote:
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 actual release and ideally some users would have time to test the "release-candidate" of QGIS before going public.

From wikipedia:
  • (complete) code freeze, in which no changes whatsoever are permitted to a portion or the entirety of the program's source code. Particularly in large software systems, any change to the source code may have unintended consequences, potentially introducing new bugs; thus, a code freeze helps ensure that a portion of the program that is known to work correctly will continue to do so. Code freezes are often employed in the final stages of development, when a particular release or iteration is being tested, but may also be used to prevent changes to one portion of a program while another is undergoing development.
Cheers,
Peter

On Wed, Oct 31, 2018 at 6:32 AM Mathieu Pellerin <[hidden email]> wrote:
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 with a bad first impression.

Math




On Wed, Oct 31, 2018 at 8:55 AM Nyall Dawson <[hidden email]> wrote:
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 changed some behavior we relied on. Not there fault, not
our fault. But end result is that it makes QGIS basically unusable for
any non gdal/ogr layers on Qt >= 5.11. And unfortunately our major
platforms only saw an upgrade to Qt 5.11 late in the bug fixing
period, which made this one slow to be identified.

https://github.com/qgis/QGIS/pull/8383 should fix it.

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)

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Giovanni Manghi
In reply to this post by Mathieu Pellerin
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 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.

cheers!

-- g --
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Régis Haubourg
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 version.

I am a big +1 on a code freeze period. 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.
 
I also think we have now a large enough code base and user base to prepare a slower release cycle with longer feature freeze, bugfix  and code freeze. We talked about it in Zanzibar, and I think advertising now that by the end of 2019, ltr should be supported for 2 years, and releases every 6 months would be nice.

What worries me in current fast cycle is that we have a lot of packaging burden for all OS, and each release has a human cost. I think it's time we just slow down just a little, but 6 months would already be something really fast for such a big software in fact. 

Cheers

Régis

 

Le mer. 31 oct. 2018 à 10:12, Giovanni Manghi <[hidden email]> a écrit :
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 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.

cheers!

-- g --
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Giovanni Manghi
In reply to this post by Giovanni Manghi
> 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 since 2.18

-- G --
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Giovanni Manghi
In reply to this post by Régis Haubourg
> 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 --
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Alessandro Pasotti-2


On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi <[hidden email]> 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 regressions admitted", at least for LTR releases.

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.

I think that it would be a good idea to create a group of volunteer testers, like we have for translators, that can regularly run test cycles (for example going through the tutorials that we already have).

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 allowed.

That said, I think that "release early release often" is still the best way we can handle release cycles.

--
Alessandro Pasotti
w3:   www.itopen.it

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Matthias Kuhn 🌍
On 10/31/18 11:08 AM, Alessandro Pasotti wrote:

>
>
> On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi
> <[hidden email] <mailto:[hidden email]>> 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 regressions admitted", at least for LTR
>     releases.
>
>
> 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.

> I think that it would be a good idea to create a group of volunteer
> testers, like we have for translators, that can regularly run test
> cycles (for example going through the tutorials that we already have)>
> 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 allowed.

I like the concept of a "release candidate".

I think by labeling a package as RC we will encourage people to

 - download and test the application
 - not use them in production
 - be relaxed about issues (because they are expected)
 - as a nice side-effect, it's also a good point in time for rolling the
   drums about an upcoming LTR.

Either we call the LTR x.y.0 version a RC (instead of the first release)
- or the 4 last weeklies before the release are labeled as RC.

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 just have to accept that this is our life
as software engineers and we all do the best we can :-)

>
> That said, I think that "release early release often" is still the best
> way we can handle release cycles.
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it <http://www.itopen.it>
>
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Giovanni Manghi
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 testing (of most functionalities, on the
3 major platforms, using multiple type/versions of QGIS and endpoints,
etc.) is a full time job, I know because  I was lucky enough to have
done it for a year and half. Without this type of effort we will
always rely on reports sent in by people that find issues here and
there while doing their normal workflow, which is ok but also has a
good chance of not finding a number of serious bugs.

cheers!

-- g --
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Richard Duivenvoorde
In reply to this post by Alessandro Pasotti-2
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 allowed.
>
> That said, I think that "release early release often" is still the best way
> we can handle release cycles.

I'm also +1 for release early and often in the pace we do now.
I think FOSS depends on users. If you have are a commercial company you
can pay testers (who create test scenario's etc etc).. costing a lot of
money. We have users who test, and yes, they do mostly around (after?)
release... So: release often.

And I DO test (and compile) all the time (almost daily compiles).
Off course more testing would maybe make some(!) issues be fixed before
a release.

And we DO have a 'feature freeze' in which we should ( try to ;-) ) only
fix bugs (as if it was a RC). So adding another RC is only
theoretical/administrive in my view.
We could be more strict though...

Bugs like the one above can always be introduced even when we had a RC.
That is one of the drawbacks of compiling for so many platforms (with so
many versions of needed libs....).

But that is also our strength!

Anyway, before releasing 3.4.1 please can other check/confirm this one:
https://issues.qgis.org/issues/20295

Regards,

Richard Duivenvoorde

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Alessandro Pasotti-2
In reply to this post by Giovanni Manghi

On Wed, Oct 31, 2018 at 11:48 AM Giovanni Manghi <[hidden email]> 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.
>
> Agreed, the more testing the better.

serious manual/semi-automated testing (of most functionalities, on the
3 major platforms, using multiple type/versions of QGIS and endpoints,
etc.) is a full time job, I know because  I was lucky enough to have
done it for a year and half. Without this type of effort we will
always rely on reports sent in by people that find issues here and
there while doing their normal workflow, which is ok but also has a
good chance of not finding a number of serious bugs.

cheers!

-- g --


Giovanni,

I'm not talking about the test cycles a company could run, but if we did a call for testers and prepared a page with instructions, we may have had a dedicated group of people (users) who is willing to help the QGIS project running test cyles, and as I said, going through the current lessons/tutorial may be sufficient.

So, the plan would be:
1. prepare a page about how to run tests (based on the lessons/tutorials)
2. ask the community via email, twitter, whatever, to join the effort of running test cycles when the code freezes
3. before any new release GOTO 2

I don't know if that will work, but worth trying.

--
Alessandro Pasotti
w3:   www.itopen.it

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Matthias Kuhn 🌍
In reply to this post by Giovanni Manghi
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.
>>
>> Agreed, the more testing the better.
>
> serious manual/semi-automated testing (of most functionalities, on the
> 3 major platforms, using multiple type/versions of QGIS and endpoints,
> etc.) is a full time job, I know because  I was lucky enough to have
> done it for a year and half. Without this type of effort we will
> always rely on reports sent in by people that find issues here and
> there while doing their normal workflow, which is ok but also has a
> good chance of not finding a number of serious bugs.

I am very much aware of the importance of testing in a structured way.
And I am very happy that we have a solid team of regular testers around you.

The limitation is that our current resources don't allow for employing
people to do more than that unless I am mistaken. So we are left with
less resources than a full-time job for that.

As a result of that, my proposal is aimed towards encouraging volunteers
to test as much as possible within the bounds of the available
resources. Tagging something as RC costs close to nothing but I have
hope that it helps to get more testing prior to a release.

If there's someone that comes up with a team of testers that is
available for serious structured testing, I'll be the last one to say no!

Cheers
Matthias

>
> cheers!
>
> -- g --
>
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Jürgen E. Fischer
In reply to this post by Matthias Kuhn 🌍
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 the first release)
> - or the 4 last weeklies before the release are labeled as RC.

Not very prominent, but that's already there:
"In the feature freeze phase that [the weekly snapshot] also acts as release
candidate."


> 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 just have to accept that this is our life
> as software engineers and we all do the best we can :-)

Sounds like the best option - other options probably end up with the same
result just with more effort ;)

And to me only people that tested the nightly before the release are allowed to
complain about preexisting bugs right after the release.  If you can jump on
the released packages right away, you should have also been able to do so with
a nightly earlier.  But this time they might even have done that and the
problem was introduced by upgrading Qt late.

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


Jürgen

--
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden             http://www.norbit.de
QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode

norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

pcav
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 that upon
release there may still be bugs, even serious, so people are  prepared
to deal with it. Google solved a similar issue by calling their programs
"beta" for a long period.

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
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Matthias Kuhn 🌍
In reply to this post by Jürgen E. Fischer
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 gamechanger.

Not that much on their own. I agree. But I don't expect them to hurt a
lot either.

>
>
>> Either we call the LTR x.y.0 version a RC (instead of the first release)
>> - or the 4 last weeklies before the release are labeled as RC.
>
> Not very prominent, but that's already there:
> "In the feature freeze phase that [the weekly snapshot] also acts as release
> candidate."

We could try to put this on the main screen of qgis.org and do some
twitter / blog announcements when 3.10 LTR weeklies are released and see
if it helps.

Cheers
Matthias


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Nyall Dawson
In reply to this post by Giovanni Manghi
On Wed, 31 Oct 2018 at 19:12, Giovanni Manghi <[hidden email]> 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 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.

Nyall
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Nyall Dawson
In reply to this post by Richard Duivenvoorde
On Wed, 31 Oct 2018 at 20:49, Richard Duivenvoorde <[hidden email]> 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
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Early 3.4 point release?

Nyall Dawson
In reply to this post by Jürgen E. Fischer
On Wed, 31 Oct 2018 at 21:23, Jürgen E. Fischer <[hidden email]> 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 E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
> Software Engineer           D-26506 Norden             http://www.norbit.de
> QGIS release manager (PSC)  Germany                    IRC: jef on FreeNode
> _______________________________________________
> QGIS-Developer mailing list
> [hidden email]
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
12