Re: [QGIS-Developer] Soft freeze for QGIS 3.0

[Tim Sutton]

Hi

Oh yeah I meant to ask if there was anything important I missed in the list.

> On 07 Nov 2017, at 00:38, Nathan Woodrow  wrote:
> 
> Hey Tim,
> 
> If I can get the first run Welcome Screen to intro QGIS 3 ready soon do you 
> think I can sneak that one in.  No API changes mainly just a bit of nice UX 
> for first run when we release.

+1 from me it will be good for our users - perhaps we can somehow link them to 
the visual changelog? http://changelog.qgis.org/en/qgis/version/3.0.0/ 
 (or the  static page that 
Richard generates from it).

Regards

Tim

> 
> Not a major issue if no.
> 
> Regards,
> Nathan
> 
> On Tue, Nov 7, 2017 at 8:32 AM, Tim Sutton  > wrote:
> Hi All 
> 
> As discussed earlier, we raised the issue of when and how to freeze at the 
> PSC meeting. We tried to take on board your various comments and came out 
> with this recommendation:
> 
> • The current master branch will be in ‘soft freeze’ with a list of allowed 
> PR’s / Future PR’s related to these features:
>   • Datum transform handling (https://github.com/qgis/QGIS/pull/5535 
> )
>   • SAGA Support (https://github.com/qgis/QGIS/pull/5155 
> )
>   • GRASS Support (https://github.com/qgis/QGIS/pull/5426 
> )
>   • Metadata write support to file system 
> (https://github.com/qgis/QGIS/pull/5379 
> )
>   • UI Widgets for drag forms (https://github.com/qgis/QGIS/pull/5467 
> )
>   * Composer refactor ( https://github.com/qgis/QGIS/pull/5486 
>  to drop bindings and new PR to come 
> for composer refactor).
> 
> Please let us know if there were other ‘must merge’ features that were 
> discussed but that I missed in the list above.
> 
> • We will hold a rolling vote put to core developer (on loomio.org 
> ) every two weeks (starting two weeks from now) 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. 
> • The paid bug fixing should commence now already regardless of when the 
> freeze will actually happen.
> 
> 
> To address specifically Mathieu’s concerns about an unspecified date in the 
> future, we do not anticipate an endless feature frenzy - the ‘soft freeze’ 
> should keep the timelines reasonable while still giving us a chance to make 
> sure that they API changes get a chance to land.
> 
> 
> I hope that woks for the majority of you. If you want o make the release come 
> faster, help by reviewing code in PR’s, testing new features and generally 
> pointing the QGIS car towards the finish line!
> 
> Regards
> 
> Tim
> 
> 
> 
>  
> 
> 
> 
> ---
> 
> Tim Sutton
> QGIS Project Steering Committee Chair
> t...@qgis.org 
> 
> 
> 
> 
> 
> ___
> 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 
> 
> 

—






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
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] Soft freeze for QGIS 3.0

[Nyall Dawson]

On 7 November 2017 at 08:32, Tim Sutton  wrote:
>
> Hi All
>
> As discussed earlier, we raised the issue of when and how to freeze at the 
> PSC meeting. We tried to take on board your various comments and came out 
> with this recommendation:
>
> • The current master branch will be in ‘soft freeze’ with a list of allowed 
> PR’s / Future PR’s related to these features:
> • Datum transform handling (https://github.com/qgis/QGIS/pull/5535)
> • SAGA Support (https://github.com/qgis/QGIS/pull/5155)
> • GRASS Support (https://github.com/qgis/QGIS/pull/5426)
> • Metadata write support to file system 
> (https://github.com/qgis/QGIS/pull/5379)
> • UI Widgets for drag forms (https://github.com/qgis/QGIS/pull/5467)
> * Composer refactor ( https://github.com/qgis/QGIS/pull/5486 to drop bindings 
> and new PR to come for composer refactor).

Hi PSC,

Many thanks for making this tricky decision. Personally I really like
the idea of a soft freeze and am glad to see that the items above will
be included in the release.

Thanks in particular to Jürgen, and my apologies for the extra work
we're causing for release!

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] Soft freeze for QGIS 3.0

[Nathan Woodrow]

Hey Tim,

If I can get the first run Welcome Screen to intro QGIS 3 ready soon do you
think I can sneak that one in.  No API changes mainly just a bit of nice UX
for first run when we release.

Not a major issue if no.

Regards,
Nathan

On Tue, Nov 7, 2017 at 8:32 AM, Tim Sutton  wrote:

> Hi All
>
> As discussed earlier, we raised the issue of when and how to freeze at the
> PSC meeting. We tried to take on board your various comments and came out
> with this recommendation:
>
> • The current master branch will be in ‘soft freeze’ with a list of
> allowed PR’s / Future PR’s related to these features:
> • Datum transform handling (https://github.com/qgis/QGIS/pull/5535)
> • SAGA Support (https://github.com/qgis/QGIS/pull/5155)
> • GRASS Support (https://github.com/qgis/QGIS/pull/5426)
> • Metadata write support to file system (https://github.com/qgis/QGIS/
> pull/5379)
> • UI Widgets for drag forms (https://github.com/qgis/QGIS/pull/5467)
> * Composer refactor ( https://github.com/qgis/QGIS/pull/5486 to drop
> bindings and new PR to come for composer refactor).
>
> Please let us know if there were other ‘must merge’ features that were
> discussed but that I missed in the list above.
>
> • We will hold a rolling vote put to core developer (on loomio.org) every
> two weeks (starting two weeks from now) 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.
> • The paid bug fixing should commence now already regardless of when the
> freeze will actually happen.
>
>
> To address specifically Mathieu’s concerns about an unspecified date in
> the future, we do not anticipate an endless feature frenzy - the ‘soft
> freeze’ should keep the timelines reasonable while still giving us a chance
> to make sure that they API changes get a chance to land.
>
>
> I hope that woks for the majority of you. If you want o make the release
> come faster, help by reviewing code in PR’s, testing new features and
> generally pointing the QGIS car towards the finish line!
>
> Regards
>
> Tim
>
>
>
>
>
>
>
> ---
>
> Tim Sutton
> QGIS Project Steering Committee Chair
> t...@qgis.org
>
>
>
>
>
> ___
> 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] Soft freeze for QGIS 3.0

[Tim Sutton]

Hi All 

As discussed earlier, we raised the issue of when and how to freeze at the PSC 
meeting. We tried to take on board your various comments and came out with this 
recommendation:

• The current master branch will be in ‘soft freeze’ with a list of allowed 
PR’s / Future PR’s related to these features:
• Datum transform handling (https://github.com/qgis/QGIS/pull/5535)
• SAGA Support (https://github.com/qgis/QGIS/pull/5155)
• GRASS Support (https://github.com/qgis/QGIS/pull/5426)
• Metadata write support to file system 
(https://github.com/qgis/QGIS/pull/5379)
• UI Widgets for drag forms (https://github.com/qgis/QGIS/pull/5467)
* Composer refactor ( https://github.com/qgis/QGIS/pull/5486 to drop 
bindings and new PR to come for composer refactor).

Please let us know if there were other ‘must merge’ features that were 
discussed but that I missed in the list above.

• We will hold a rolling vote put to core developer (on loomio.org) every two 
weeks (starting two weeks from now) 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. 
• The paid bug fixing should commence now already regardless of when the freeze 
will actually happen.


To address specifically Mathieu’s concerns about an unspecified date in the 
future, we do not anticipate an endless feature frenzy - the ‘soft freeze’ 
should keep the timelines reasonable while still giving us a chance to make 
sure that they API changes get a chance to land.


I hope that woks for the majority of you. If you want o make the release come 
faster, help by reviewing code in PR’s, testing new features and generally 
pointing the QGIS car towards the finish line!

Regards

Tim



 



---

Tim Sutton
QGIS Project Steering Committee Chair
t...@qgis.org




___
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] Plugin [1353] Search Layers approval notification.

[noreply]

Plugin Search Layers approval by rduivenvoorde.
The plugin version "[1353] Search Layers 0.2" is now approved
Link: http://plugins.qgis.org/plugins/searchlayers/
___
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] pyqgis: new sqlite layer - no records in attribute table

[Martin Landa]

Hi,

2017-11-06 17:17 GMT+01:00 Jürgen E. Fischer :
> Don't use the provider directly, but the layer, ie. startEditing, addFeature,
> commitChanges - or layer.reload() after changing via the provider.

thanks for quick feedback, I will try. Martin

PS: sorry for the same messages (they were blocked due limit of 80Kb)


-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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] loadLayerDefinition does not respect relative path from qlr file

[René-Luc Dhont]

Hi Devs,

I will propose a PR to fix it.

Regards,
René-Luc

Le 06/11/2017 à 17:23, René-Luc Dhont a écrit :

Hi Devs,

I have found a bug in 2.18 that annoy me a lot:
* I can't load a layer definition in an existing project because the 
relative path in the layer definition is interpreted from the project 
file and not the layer definition file (.qlr)


So the layer definition can only be used in an not already saved project.

Do you know, how to force the absolute path ?

Regards,



___
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] loadLayerDefinition does not respect relative path from qlr file

[René-Luc Dhont]

Hi Devs,

I have found a bug in 2.18 that annoy me a lot:
* I can't load a layer definition in an existing project because the 
relative path in the layer definition is interpreted from the project 
file and not the layer definition file (.qlr)


So the layer definition can only be used in an not already saved project.

Do you know, how to force the absolute path ?

Regards,

___
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] pyqgis: new sqlite layer - no records in attribute table

[Jürgen E . Fischer]

Hi Martin,

On Mon, 06. Nov 2017 at 16:51:30 +0100, Martin Landa wrote:
> layer = QgsVectorLayer("test.sqlite", "test", "ogr") # empty layer
> created by GDAL
> layer.dataProvider().addAttributes([...])
> layer.updateFields()

Don't use the provider directly, but the layer, ie. startEditing, addFeature,
commitChanges - or layer.reload() after changing via the provider.

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


signature.asc
Description: PGP signature
___
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] pyqgis: new sqlite layer - no records in attribute table

[Martin Landa]

Hi,

a new SQLite layer created using Python libraries:

layer = QgsVectorLayer("test.sqlite", "test", "ogr") # empty layer
created by GDAL
layer.dataProvider().addAttributes([...])
layer.updateFields()

feats = []
for ...:
   feat=QgsFeature()
   ...
   feats.append(feat)

layer.AddFeatures(feats)

The new layer is loaded (in pyqgis code), features can be identified,
but attribute table is empty (0 filtered features), see attached
screenshot [1]. When I load created SQLite layer via GUI, attribute
table is filled.

Any idea what is missing/wrong in code? Thanks, Ma

[1] http://geo102.fsv.cvut.cz/~landa/tmp/qgis-no-attrs.png

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
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] 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
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] 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
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] PROPOSAL: change how we manage the 3.0 release process

[Andreas Neumann]

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_filter=1%5B%5D=tracker_id%5Btracker_id%5D=%3D%5Btracker_id%5D%5B%5D=1%5B%5D=cf_10%5Bcf_10%5D=%3D%5Bcf_10%5D%5B%5D=1%5B%5D=status_id%5Bstatus_id%5D=o%5B%5D=cf_9%5Bcf_9%5D=%3D%5Bcf_9%5D%5B%5D=master%5B%5D=%5B%5D=tracker%5B%5D=status%5B%5D=priority%5B%5D=subject%5B%5D=assigned_to%5B%5D=updated_on%5B%5D=category%5B%5D=cf_8_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
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] PROPOSAL: change how we manage the 3.0 release process

[Matthias Kuhn]

Hi Tim

On 11/06/2017 01:57 PM, Tim Sutton wrote:
> Hi
>
>> On 06 Nov 2017, at 12:00, Matthias Kuhn > > 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
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] 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"  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"  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@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer [1]


___

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

[Matthias Kuhn]

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" > > 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@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
>> 

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

[Mathieu Pellerin]

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"  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"  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 listqgis-develo...@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] PROPOSAL: change how we manage the 3.0 release process

[Tim Sutton]

Hi

> On 06 Nov 2017, at 12:00, Matthias Kuhn  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
>> 
>> —
>> 
>> 
>> 
>> 
>> 
>> 
>> 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
>> 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

—






Tim Sutton

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

[Andreas Neumann]

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"  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@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@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@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___
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] QgsJsonUtils usage to import data from an Android app

[Andrea Rossi]

Hi all

I am involved in small compass android app project; my job should be to
develop a plugin capable of import bedding data (dip and dip direction of
single points) into qgis.
Which would be your choice about the data format? Would be a good idea to
use QgsJsonUtils to import a GeoJson file?
thanks in advance to any suggestion
___
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] 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"  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 listqgis-develo...@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] PROPOSAL: change how we manage the 3.0 release process

[Andreas Neumann]

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

[Matthias Kuhn]

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@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] QgsDataProvider and caching: any defined behaviour?

[Régis Haubourg]

Hi Richard,

 one guy said that once:

There are only two hard things in Computer Science: cache invalidation and
naming things.

-- Phil Karlton
Joke apart, current situation is not good for sure, especially for WFS
which has a cache, and that should be handled better in transactional WFS-T
use cases.

For Postgres, we recently hit a problem, not related to big datasets, but
to very laggy database and network, that led the client to switch back to
WFS, with a its cache giving an impression of reactive application.
Cache invalidation seems especially complicated currently when you have
some business logic inside the database (triggers), and even more when
using Transaction groups, where any action is commited on the fly in the
database. It starts to be tricky keeping in sync the snapping index cache
and the attribute table cache only for features concerned by the
transaction.
Matthias also pointed out that we don't have very specific cache
invalidation signals for attribute table, and we should have some to be
able to invalidate only the features concerned by a transaction (for
instance).

So I think we must go that way, at least to consolidate current features,
but I think should be handled very seriously by a group of dev knowing each
parts of the application. That is an excellent candidate topic for Madeyra.

Régis

2017-11-06 11:05 GMT+01:00 Richard Duivenvoorde :

> Working with a rather large dataset (16M timebased points), I have trouble
> working with this in QGIS, using both the Postgis-provider OR the
> WFS-provider.
>
> As data is properly indexed, retrieving a selected area is fine.
>
> BUT as soon as you try to use the attribute table, I-tool or for example
> the TimeManager, QGIS stalls.
>
> I think(!) because apparently both providers are requesting all data again
> from their datasource, sometimes even ignoring the current extent (WFS).
>
> While, it seems more appropriate to 'just use what you already have': the
> dataprovider/QGIS already has all features (both geom + attributes in case
> of WFS for example), so WHY should it request all data again
> (data-freshness?)?
>
> Are others having this problems too?
>
> Could adding a 'Caching-option' for the QgsDataProvider be a
> reasonable/viable option:
> - if 'data caching' is enabled, the data will be retrieved only once (per
> extent probably). So showing the Attribute table, I-tool info, or using
> TimeManager/Query should be relatively easy/fast as the features are
> locally (or in memory) cached.
> - as soon as you want 'fresh' data you disable the caching temporarily,
> and new data will be requested (as it is doing now apparently).
>
> Or am I missing something (I see there is an option for attributetable
> caching...)?
>
> Not sure about other countries, but here in NL governmental institutes
> start serving huge dataset more and more, either as WMS/WCS/WFS services,
> or more and more as REST/GeoJSON services.
>
> Anybody has some insights ideas about this?
>
> Regards,
>
> Richard Duivenvoorde
> ___
> 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] 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)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] 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)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] [Qgis-psc] PROPOSAL: change how we manage the 3.0 release process

[Nathan Woodrow]

I agree.  I very much like the fixed schedule normally just with 3.0 being
such a major rework of core stuff maybe just tweaking it for this release
is the best plan.  The fixed schedule has been great for clients to know
when they are going to get a new release and what will be in it.

- Nathan

On Mon, Nov 6, 2017 at 8:10 PM, Alessandro Pasotti 
wrote:

> I agree with Matthias, having a fixed/predictable schedule is very
> important for planning, but for QGIS3 we invested so much time and efforts
> in fixing the API that it would be a pity if we miss the occasion.
>
> I would be in favor of grant some more flexibility to this 3.0 release
> while keeping the fixed release cycles.
>
> Of course we should try harder to meet the deadlines in he future major
> releases.
>
>
>
> On Mon, Nov 6, 2017 at 11:03 AM, Régis Haubourg 
> wrote:
>
>> Hi Tim,
>>
>>  I agree QGIS 3.0 is sort of an exception, we have a lot a major
>> refactoring that need to land in it.
>>
>> However, I think we should keep fixed date releases within major version
>> lifecycle, and in the same time improve our feature roadmap planning. Let
>> me explain why.
>>
>>  - Release when ready would imply that we all can announce in advance
>> what feature we will bring in each version. By now, we are not structured
>> for that I think.
>>  - Fixed date releases are very good for users, developpers and funders
>> to plan work and anticipate. It also allows to avoid those huge delays we
>> have currently in QGIS3, with too much untested nex features. Release often
>> is the key for real user testing.
>>
>> So my vote would be to allow unfixed schedule for major releases, but
>> with a better project management of critical features and API break we need
>> in it, and keep fixed date minor releases.
>>
>> My two cents,
>> Regards
>> Régis
>>
>> 2017-11-06 10:43 GMT+01:00 Tim Sutton :
>>
>>> 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-psc mailing list
>>> qgis-...@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>
>>
>> ___
>> 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
>
> 

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

[Alessandro Pasotti]

I agree with Matthias, having a fixed/predictable schedule is very
important for planning, but for QGIS3 we invested so much time and efforts
in fixing the API that it would be a pity if we miss the occasion.

I would be in favor of grant some more flexibility to this 3.0 release
while keeping the fixed release cycles.

Of course we should try harder to meet the deadlines in he future major
releases.



On Mon, Nov 6, 2017 at 11:03 AM, Régis Haubourg 
wrote:

> Hi Tim,
>
>  I agree QGIS 3.0 is sort of an exception, we have a lot a major
> refactoring that need to land in it.
>
> However, I think we should keep fixed date releases within major version
> lifecycle, and in the same time improve our feature roadmap planning. Let
> me explain why.
>
>  - Release when ready would imply that we all can announce in advance what
> feature we will bring in each version. By now, we are not structured for
> that I think.
>  - Fixed date releases are very good for users, developpers and funders to
> plan work and anticipate. It also allows to avoid those huge delays we have
> currently in QGIS3, with too much untested nex features. Release often is
> the key for real user testing.
>
> So my vote would be to allow unfixed schedule for major releases, but with
> a better project management of critical features and API break we need in
> it, and keep fixed date minor releases.
>
> My two cents,
> Regards
> Régis
>
> 2017-11-06 10:43 GMT+01:00 Tim Sutton :
>
>> 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-psc mailing list
>> qgis-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>
>
> ___
> 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

[QGIS-Developer] QgsDataProvider and caching: any defined behaviour?

[Richard Duivenvoorde]

Working with a rather large dataset (16M timebased points), I have 
trouble working with this in QGIS, using both the Postgis-provider OR 
the WFS-provider.


As data is properly indexed, retrieving a selected area is fine.

BUT as soon as you try to use the attribute table, I-tool or for example 
the TimeManager, QGIS stalls.


I think(!) because apparently both providers are requesting all data 
again from their datasource, sometimes even ignoring the current extent 
(WFS).


While, it seems more appropriate to 'just use what you already have': 
the dataprovider/QGIS already has all features (both geom + attributes 
in case of WFS for example), so WHY should it request all data again 
(data-freshness?)?


Are others having this problems too?

Could adding a 'Caching-option' for the QgsDataProvider be a 
reasonable/viable option:
- if 'data caching' is enabled, the data will be retrieved only once 
(per extent probably). So showing the Attribute table, I-tool info, or 
using TimeManager/Query should be relatively easy/fast as the features 
are locally (or in memory) cached.
- as soon as you want 'fresh' data you disable the caching temporarily, 
and new data will be requested (as it is doing now apparently).


Or am I missing something (I see there is an option for attributetable 
caching...)?


Not sure about other countries, but here in NL governmental institutes 
start serving huge dataset more and more, either as WMS/WCS/WFS 
services, or more and more as REST/GeoJSON services.


Anybody has some insights ideas about this?

Regards,

Richard Duivenvoorde
___
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] [Qgis-psc] PROPOSAL: change how we manage the 3.0 release process

[Régis Haubourg]

Hi Tim,

 I agree QGIS 3.0 is sort of an exception, we have a lot a major
refactoring that need to land in it.

However, I think we should keep fixed date releases within major version
lifecycle, and in the same time improve our feature roadmap planning. Let
me explain why.

 - Release when ready would imply that we all can announce in advance what
feature we will bring in each version. By now, we are not structured for
that I think.
 - Fixed date releases are very good for users, developpers and funders to
plan work and anticipate. It also allows to avoid those huge delays we have
currently in QGIS3, with too much untested nex features. Release often is
the key for real user testing.

So my vote would be to allow unfixed schedule for major releases, but with
a better project management of critical features and API break we need in
it, and keep fixed date minor releases.

My two cents,
Regards
Régis

2017-11-06 10:43 GMT+01:00 Tim Sutton :

> 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-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
___
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] 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
> 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] PROPOSAL: change how we manage the 3.0 release process

[Tim Sutton]

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
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] Request for freeze exemption: datum transform handling

[Régis Haubourg]

Hi Nyall,
thanks for raising that. For those who discover that work, it will fix
severe issues we currently have for instance when copy/pasting features
between two layers relying on SRS having different datum. It can severely
alter data precision, and I agree this is a much needed feature for a
professional GIS.

Cheers
Régis

2017-11-06 9:10 GMT+01:00 Nyall Dawson :

> Hi all,
>
> I would like to request an exemption from the feature freeze in order
> to merge https://github.com/qgis/QGIS/pull/5535 and a future follow up
> by Denis which will address the GUI component of that work.
>
> Because of the heavy API breakage that this PR involves, it needs to
> be merged before API freeze. I also consider this a crucial
> "must-have" for QGIS 3.x, given that it sets in place a framework
> which is required for features that will become highly in-demand
> during the lifetime of 3.x (namely - support for dynamic datum
> transforms without this, QGIS will become a non-option for
> Australian users in 2020).
>
> Not to put to much emphasis on this, but this is a kind of
> "make-or-break" decision, where not fixing this part of the API could
> really slow QGIS' current growth rate and force our users to use
> alternative programs.
>
> 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
___
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