[QGIS-Developer] PROPOSAL: change how we manage the 3.0 release process

[Andreas Neumann]

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" <a.neumann at carto.net> 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" <a.neumann at carto.net> 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
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]

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


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


 

Links:
------
[1] https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20171106/48547f7c/attachment.html>