Re: PROPOSAL: change how we manage the 3.0 release process

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

Re: PROPOSAL: change how we manage the 3.0 release process

Matthias Kuhn 🌍

Hi Tim,

Thanks for raising this, I think it's very important to have everyone on board and especially have Jürgen as Release Manager agree on the plan.

For what I think, the 3.0 release is a very special release since we have the unique possibility to work on the API and to some degree on workflows. Actually this is in my opinion not only a possibility but an obligation as we will severely disappoint plugin developers and users if we break things again in the near future.

The calls for exemption that we have now are mostly backed up with the argument that right now is the right time to do certain things. This argument can not be repeated for future 3.x releases. I would therefore propose not to discuss the fixed release schedule in general, it has IMO worked out quite nicely. Instead I would like the PSC to discuss a flexible handling of this particular major release with the very specific requirements.

Best regards

Matthias

On 11/06/2017 10:43 AM, Tim Sutton wrote:
Hi All

We have our PSC meeting tonight and I have added an agenda item about feature freeze exceptions. I will respond immediately after the meeting with any decision that has been reached, or if we are not able to reach a consensus I will put it to a general members vote. 

As Jürgen is release manager, I would prefer that we have his agreement and buy-in (he has already stated a contrary opinion to lifting the freeze - http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Feature-freeze-Paid-developer-activities-for-QGIS-3-0-tp5340245p5340300.html). 

Probably more accurately I should state that Jürgen already agreed in Girona to go to a fixed release schedule in preference to a  ‘when it is ready’ schedule as was originally planned.

At the risk of severely irritating Jürgen (sorry!), why don’t we move back to a ‘release when ready’ approach which might also have the happy by-product of being less work for him since he only needs to deal with the process once when the release is deemed ready. 

One simple mechanism we could do is have a rolling voting member’s vote (e.g. at then end of each month) with a simple question “shall we freeze”? Once we have quorum on that vote, we go ahead and freeze and Jürgen can pretty much ignore 3.x in his release planning until that vote passes. We also have the by-product that we cannot tell our users / customers / fans when the release will be ready but by-and-large I think the outcome will be better since we all will be dancing to the same tune and we can make sure 3.0 has everything in it that we think it should have without compromises.

I also propose that the paid bug fixing should commence now already regardless of when the freeze will actually happen.


Our PSC meeting is at 8pm CET (sorry thats an awful time for you Nyall) and anybody is always welcome to sit in the call if you wish you raise your concerns in person (or send me any notes for things that you would like raised on your behalf).


Regards

Tim






Tim Sutton

Co-founder: Kartoza
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

Kartoza is a merger between Linfiniti and Afrispatial



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Jürgen E. Fischer
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
> Instead I would like the PSC to discuss a flexible handling of this
> particular major release with the very specific requirements.

The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


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

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

Re: PROPOSAL: change how we manage the 3.0 release process

Jürgen E. Fischer
Hi,

On Mon, 06. Nov 2017 at 11:17:11 +0100, Jürgen E. Fischer wrote:
> That would have been my preference anyway and returning to it is ok with me.

I'm referring to the "release when ready" policy for 3.0 here.

After that we will return to the regular fixed release schedule.



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

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

Re: PROPOSAL: change how we manage the 3.0 release process

Matthias Kuhn 🌍
In reply to this post by Jürgen E. Fischer

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Andreas Neumann-4

It would be nice if the core devs could agree on items that need to go into 3.0 before feature freeze - so we don't have to delay longer than necessary.

The other question is how to deal with features that could also be done in 3.2. Can they also go into 3.0 if they are ready before the feature freeze? In other words: do we already have a feature freeze but allow exceptions where core devs agree on? Or will the whole feature freeze be delayed?

Andreas

On 2017-11-06 12:23, Matthias Kuhn wrote:

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Mathieu Pellerin
Hmm we just jumped from discussing feature freeze exception to delaying release, is that correct?

Personally, I'm big +1 for feature freeze exceptions-only *if* release date remains achievable. If not, it seems there is a consensus on adding additional time to this dev cycle, which remains preferable to shipping 3.0 with crucial architectural changes and additions missing.

That said I'm a -1 to go into a "release whenever it's ready" mode without a firm agreed upon (delayed) release date.

M

On Nov 6, 2017 6:59 PM, "Andreas Neumann" <[hidden email]> wrote:

It would be nice if the core devs could agree on items that need to go into 3.0 before feature freeze - so we don't have to delay longer than necessary.

The other question is how to deal with features that could also be done in 3.2. Can they also go into 3.0 if they are ready before the feature freeze? In other words: do we already have a feature freeze but allow exceptions where core devs agree on? Or will the whole feature freeze be delayed?

Andreas

On 2017-11-06 12:23, Matthias Kuhn wrote:

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Andreas Neumann-4

Well - in my opinion, if we delay the feature freeze we also have to delay the release.

QGIS 3 still crashes several times a day (esp. if you work with editing, complex forms and PostgreSQL transaction mode). QGIS 3 is way more unstable than QGIS 2.18. We need at least 1.5 months, better 2 months between feature freeze and release. If we move feature freeze, say, until end of November, we can't release in December or we would loose the good reputation that QGIS built in the last couple of years.

That is just my personal opinion. I use QGIS 3 a lot - and it is not a pleasant piece of software currently, but a major source of headaches and grief, not because of UI or missing features, but because of all the crashes I often experience (and are often hard to reproduce and report).

Andreas

On 2017-11-06 13:17, Mathieu Pellerin wrote:

Hmm we just jumped from discussing feature freeze exception to delaying release, is that correct?
 
Personally, I'm big +1 for feature freeze exceptions-only *if* release date remains achievable. If not, it seems there is a consensus on adding additional time to this dev cycle, which remains preferable to shipping 3.0 with crucial architectural changes and additions missing.
 
That said I'm a -1 to go into a "release whenever it's ready" mode without a firm agreed upon (delayed) release date.
 
M

On Nov 6, 2017 6:59 PM, "Andreas Neumann" <[hidden email]> wrote:

It would be nice if the core devs could agree on items that need to go into 3.0 before feature freeze - so we don't have to delay longer than necessary.

The other question is how to deal with features that could also be done in 3.2. Can they also go into 3.0 if they are ready before the feature freeze? In other words: do we already have a feature freeze but allow exceptions where core devs agree on? Or will the whole feature freeze be delayed?

Andreas

On 2017-11-06 12:23, Matthias Kuhn wrote:

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Tim Sutton-6
In reply to this post by Matthias Kuhn 🌍
Hi

On 06 Nov 2017, at 12:00, Matthias Kuhn <[hidden email]> wrote:

Hi Tim,

Thanks for raising this, I think it's very important to have everyone on board and especially have Jürgen as Release Manager agree on the plan.

For what I think, the 3.0 release is a very special release since we have the unique possibility to work on the API and to some degree on workflows. Actually this is in my opinion not only a possibility but an obligation as we will severely disappoint plugin developers and users if we break things again in the near future.

The calls for exemption that we have now are mostly backed up with the argument that right now is the right time to do certain things. This argument can not be repeated for future 3.x releases. I would therefore propose not to discuss the fixed release schedule in general, it has IMO worked out quite nicely. Instead I would like the PSC to discuss a flexible handling of this particular major release with the very specific requirements.


Thanks for your reply Matthias. Sorry I was unclear - 100% agreed that we should see the regular 4 month release cycle in place - I intended ‘release when it’s ready’ to apply only to QGIS 3.0. We basically go into a mode where we are in ‘soft freeze’ - where there should be agreement before merging PR’s and when we agree (e.g. by monthly vote) that all exceptions are done, we enter a formal freeze. 

Regards

Tim

Best regards

Matthias

On 11/06/2017 10:43 AM, Tim Sutton wrote:
Hi All

We have our PSC meeting tonight and I have added an agenda item about feature freeze exceptions. I will respond immediately after the meeting with any decision that has been reached, or if we are not able to reach a consensus I will put it to a general members vote. 

As Jürgen is release manager, I would prefer that we have his agreement and buy-in (he has already stated a contrary opinion to lifting the freeze - http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Feature-freeze-Paid-developer-activities-for-QGIS-3-0-tp5340245p5340300.html). 

Probably more accurately I should state that Jürgen already agreed in Girona to go to a fixed release schedule in preference to a  ‘when it is ready’ schedule as was originally planned.

At the risk of severely irritating Jürgen (sorry!), why don’t we move back to a ‘release when ready’ approach which might also have the happy by-product of being less work for him since he only needs to deal with the process once when the release is deemed ready. 

One simple mechanism we could do is have a rolling voting member’s vote (e.g. at then end of each month) with a simple question “shall we freeze”? Once we have quorum on that vote, we go ahead and freeze and Jürgen can pretty much ignore 3.x in his release planning until that vote passes. We also have the by-product that we cannot tell our users / customers / fans when the release will be ready but by-and-large I think the outcome will be better since we all will be dancing to the same tune and we can make sure 3.0 has everything in it that we think it should have without compromises.

I also propose that the paid bug fixing should commence now already regardless of when the freeze will actually happen.


Our PSC meeting is at 8pm CET (sorry thats an awful time for you Nyall) and anybody is always welcome to sit in the call if you wish you raise your concerns in person (or send me any notes for things that you would like raised on your behalf).


Regards

Tim



<KartozaNewLogoThumbnail.jpg>



Tim Sutton

Co-founder: Kartoza
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

Kartoza is a merger between Linfiniti and Afrispatial



_______________________________________________
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






Tim Sutton

Co-founder: Kartoza
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

Kartoza is a merger between Linfiniti and Afrispatial


_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Mathieu Pellerin
In reply to this post by Andreas Neumann-4
I still think it's worth considering feature freeze exceptions ( versus a feature freeze delay ). It'd be a shame for this debate/discussion not to take place.

As for stability, I've had a rather positive experience with current master builds in terms of stability. Hope you can dissect the issues that are haunting you in time :)

Math

On Nov 6, 2017 7:53 PM, "Andreas Neumann" <[hidden email]> wrote:

Well - in my opinion, if we delay the feature freeze we also have to delay the release.

QGIS 3 still crashes several times a day (esp. if you work with editing, complex forms and PostgreSQL transaction mode). QGIS 3 is way more unstable than QGIS 2.18. We need at least 1.5 months, better 2 months between feature freeze and release. If we move feature freeze, say, until end of November, we can't release in December or we would loose the good reputation that QGIS built in the last couple of years.

That is just my personal opinion. I use QGIS 3 a lot - and it is not a pleasant piece of software currently, but a major source of headaches and grief, not because of UI or missing features, but because of all the crashes I often experience (and are often hard to reproduce and report).

Andreas

On 2017-11-06 13:17, Mathieu Pellerin wrote:

Hmm we just jumped from discussing feature freeze exception to delaying release, is that correct?
 
Personally, I'm big +1 for feature freeze exceptions-only *if* release date remains achievable. If not, it seems there is a consensus on adding additional time to this dev cycle, which remains preferable to shipping 3.0 with crucial architectural changes and additions missing.
 
That said I'm a -1 to go into a "release whenever it's ready" mode without a firm agreed upon (delayed) release date.
 
M

On Nov 6, 2017 6:59 PM, "Andreas Neumann" <[hidden email]> wrote:

It would be nice if the core devs could agree on items that need to go into 3.0 before feature freeze - so we don't have to delay longer than necessary.

The other question is how to deal with features that could also be done in 3.2. Can they also go into 3.0 if they are ready before the feature freeze? In other words: do we already have a feature freeze but allow exceptions where core devs agree on? Or will the whole feature freeze be delayed?

Andreas

On 2017-11-06 12:23, Matthias Kuhn wrote:

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Matthias Kuhn 🌍
In reply to this post by Andreas Neumann-4

Hi,

On 11/06/2017 01:53 PM, Andreas Neumann wrote:

Well - in my opinion, if we delay the feature freeze we also have to delay the release.

QGIS 3 still crashes several times a day (esp. if you work with editing, complex forms and PostgreSQL transaction mode).

QGIS 3 is still not even released while 2.18 received more path releases than any QGIS release before (except for 2.14). QGIS 2.99 is probably more stable already now than QGIS 2.18.0 has been.

QGIS 3 is way more unstable than QGIS 2.18. We need at least 1.5 months, better 2 months between feature freeze and release. If we move feature freeze, say, until end of November, we can't release in December or we would loose the good reputation that QGIS built in the last couple of years.

I would prefer to keep feature freeze in place and only discuss for what we need exemptions. At the same time we can already improve the quality of the release and perform bugfixing. Based on the aforementioned discussion we can decide how much time we need.

That is just my personal opinion. I use QGIS 3 a lot - and it is not a pleasant piece of software currently, but a major source of headaches and grief, not because of UI or missing features, but because of all the crashes I often experience (and are often hard to reproduce and report).

Can you point me towards the issue reports with the information from the crash dialog?

Thanks
Matthias

Andreas

On 2017-11-06 13:17, Mathieu Pellerin wrote:

Hmm we just jumped from discussing feature freeze exception to delaying release, is that correct?
 
Personally, I'm big +1 for feature freeze exceptions-only *if* release date remains achievable. If not, it seems there is a consensus on adding additional time to this dev cycle, which remains preferable to shipping 3.0 with crucial architectural changes and additions missing.
 
That said I'm a -1 to go into a "release whenever it's ready" mode without a firm agreed upon (delayed) release date.
 
M

On Nov 6, 2017 6:59 PM, "Andreas Neumann" <[hidden email]> wrote:

It would be nice if the core devs could agree on items that need to go into 3.0 before feature freeze - so we don't have to delay longer than necessary.

The other question is how to deal with features that could also be done in 3.2. Can they also go into 3.0 if they are ready before the feature freeze? In other words: do we already have a feature freeze but allow exceptions where core devs agree on? Or will the whole feature freeze be delayed?

Andreas

On 2017-11-06 12:23, Matthias Kuhn wrote:

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Andreas Neumann-4
In reply to this post by Mathieu Pellerin

Hi,

That is, what I was trying to find out: are we aiming for a "soft feature freeze" as Tim described it - meaning that every new feature or major API change that is merged now, needs approval from some core devs - or are we still allowing any new feature to land in QGIS 3?

In any case - I fear that the bug fixing time is getting too short now, if we aim at a december release.

@Matthieu: as I said, my crashes are often happening with forms, relations and PostgreSQL transaction mode. Just recently, QGIS crashed every time I used the Identify tool - really scary! Matthias fixed that particular problem (related to relation reference widgets) meanwhile - but there are more such crashes ...

Even more scary: QGIS is marking features as if they were manipulated / edited (displayed as red in the side bar in the forms mode) although I did not enter edit mode. Really scary and not trustworthy!

Definitely QGIS 3 is nowhere near to being production ready if you need to rely on it as a PostgreSQL editing platform with lots of relations and complex forms and widgets.

Andreas

On 2017-11-06 13:58, Mathieu Pellerin wrote:

I still think it's worth considering feature freeze exceptions ( versus a feature freeze delay ). It'd be a shame for this debate/discussion not to take place.
 
As for stability, I've had a rather positive experience with current master builds in terms of stability. Hope you can dissect the issues that are haunting you in time :)
 
Math

On Nov 6, 2017 7:53 PM, "Andreas Neumann" <[hidden email]> wrote:

Well - in my opinion, if we delay the feature freeze we also have to delay the release.

QGIS 3 still crashes several times a day (esp. if you work with editing, complex forms and PostgreSQL transaction mode). QGIS 3 is way more unstable than QGIS 2.18. We need at least 1.5 months, better 2 months between feature freeze and release. If we move feature freeze, say, until end of November, we can't release in December or we would loose the good reputation that QGIS built in the last couple of years.

That is just my personal opinion. I use QGIS 3 a lot - and it is not a pleasant piece of software currently, but a major source of headaches and grief, not because of UI or missing features, but because of all the crashes I often experience (and are often hard to reproduce and report).

Andreas

On 2017-11-06 13:17, Mathieu Pellerin wrote:

Hmm we just jumped from discussing feature freeze exception to delaying release, is that correct?
 
Personally, I'm big +1 for feature freeze exceptions-only *if* release date remains achievable. If not, it seems there is a consensus on adding additional time to this dev cycle, which remains preferable to shipping 3.0 with crucial architectural changes and additions missing.
 
That said I'm a -1 to go into a "release whenever it's ready" mode without a firm agreed upon (delayed) release date.
 
M

On Nov 6, 2017 6:59 PM, "Andreas Neumann" <[hidden email]> wrote:

It would be nice if the core devs could agree on items that need to go into 3.0 before feature freeze - so we don't have to delay longer than necessary.

The other question is how to deal with features that could also be done in 3.2. Can they also go into 3.0 if they are ready before the feature freeze? In other words: do we already have a feature freeze but allow exceptions where core devs agree on? Or will the whole feature freeze be delayed?

Andreas

On 2017-11-06 12:23, Matthias Kuhn wrote:

Hi Jürgen,


On 11/06/2017 11:17 AM, Jürgen E. Fischer wrote:
Hi Matthias,

On Mon, 06. Nov 2017 at 11:00:04 +0100, Matthias Kuhn wrote:
Instead I would like the PSC to discuss a flexible handling of this
particular major release with the very specific requirements.
The "release when ready" policy was made for 3.0 and only for 3.0.  The plan is
to return to the original way of doing release afterwards.

That would have been my preference anyway and returning to it is ok with me.

Nice, looks like everyone agrees.
Can we schedule a release-plan meeting with involved devs to discuss if/when it's ready?

Thanks a lot
Matthias

Although IIRC the move to a fixed date was made because others argued that they
need to communicate a date to their customers.


Jürgen



_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Matthias Kuhn 🌍
In reply to this post by Tim Sutton-6

Hi Tim

On 11/06/2017 01:57 PM, Tim Sutton wrote:
Hi

On 06 Nov 2017, at 12:00, Matthias Kuhn <[hidden email]> wrote:

Hi Tim,

Thanks for raising this, I think it's very important to have everyone on board and especially have Jürgen as Release Manager agree on the plan.

For what I think, the 3.0 release is a very special release since we have the unique possibility to work on the API and to some degree on workflows. Actually this is in my opinion not only a possibility but an obligation as we will severely disappoint plugin developers and users if we break things again in the near future.

The calls for exemption that we have now are mostly backed up with the argument that right now is the right time to do certain things. This argument can not be repeated for future 3.x releases. I would therefore propose not to discuss the fixed release schedule in general, it has IMO worked out quite nicely. Instead I would like the PSC to discuss a flexible handling of this particular major release with the very specific requirements.


Thanks for your reply Matthias. Sorry I was unclear - 100% agreed that we should see the regular 4 month release cycle in place - I intended ‘release when it’s ready’ to apply only to QGIS 3.0. We basically go into a mode where we are in ‘soft freeze’ - where there should be agreement before merging PR’s and when we agree (e.g. by monthly vote) that all exceptions are done, we enter a formal freeze. 


Thanks Tim, that sounds like a good path forward. To avoid being in this state for too long I'd prefer to go for 2 weeks instead of a month and agree beforehand on what needs to be done. This way we also have a clear list of criteria for decision making.

Regards
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
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: change how we manage the 3.0 release process

Andreas Neumann-4
In reply to this post by Matthias Kuhn 🌍

Hi,


Can you point me towards the issue reports with the information from the crash dialog?


I will try to report the crashes better. However, the crashes are often not so easy to reproduce and not so easy to describe what I did. But they happen quite often.

In general there are 22 open issues with crashes for master:

https://issues.qgis.org/projects/qgis/issues?utf8=%E2%9C%93&set_filter=1&f%5B%5D=tracker_id&op%5Btracker_id%5D=%3D&v%5Btracker_id%5D%5B%5D=1&f%5B%5D=cf_10&op%5Bcf_10%5D=%3D&v%5Bcf_10%5D%5B%5D=1&f%5B%5D=status_id&op%5Bstatus_id%5D=o&f%5B%5D=cf_9&op%5Bcf_9%5D=%3D&v%5Bcf_9%5D%5B%5D=master&f%5B%5D=&c%5B%5D=tracker&c%5B%5D=status&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=assigned_to&c%5B%5D=updated_on&c%5B%5D=category&c%5B%5D=cf_8&group_by=

and in addition there are 47 open issues with crashes on 2.18 - many of them are also valid for master.

And the majority of QGIS users haven't really started testing QGIS 3. So we should be prepared for many more issues.

Andreas


_______________________________________________
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: PROPOSAL: change how we manage the 3.0 release process

Matthias Kuhn 🌍

Hi

On 11/06/2017 02:44 PM, Andreas Neumann wrote:

Hi,


Can you point me towards the issue reports with the information from the crash dialog?


I will try to report the crashes better. However, the crashes are often not so easy to reproduce and not so easy to describe what I did. But they happen quite often.

I understand your frustration as an early adopter, please don't get me wrong. You report a lot and with high quality Please keep this up.

I'll have a look at those crashes, but let's keep focused here and discuss the release strategy.

I think especially with the demand for stability you raise here it's important that we don't talk about "lifting feature freeze" but about what can we do to ship:

a) everything we want from a code-perspective
b) a high quality, stable release (on which we can and will also improve in subsequent patch releases)
c) within a finite timeframe

Best regards
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
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: change how we manage the 3.0 release process

Tom Chadwin
Matthias Kuhn 🌍 wrote
> I think especially with the demand for stability you raise here it's
> important that we don't talk about "lifting feature freeze" but about
> what can we do to ship:
>
> a) everything we want from a code-perspective
> b) a high quality, stable release (on which we can and will also improve
> in subsequent patch releases)
> c) within a finite timeframe

d) with all API changes complete from 2.0 and no need for API breakage until
v4.

I'm really pleased Andreas has raised the bugfixing question so forcefully.
For me, API breakage and stability are the issues of much greater importance
over everything else. Non-API-breaking features can wait until 3.2. The more
features we introduce during soft feature-freeze, the less time *those*
features get during bugfixing.

Tom



-----
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
_______________________________________________
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