Re: [QGIS-Developer] Qgis 3.0 plugin dependencies status

[Borys Jurgiel]

Guys,

Unfortunately all I can do now is to book the necessary time this autumn. First 
I have to 
address a few bugfixes in my badly limited time for QGIS.
If nobody makes the QEP before, I'll come back to it after the summer.

Regards,
Borys

Dnia piątek, 2 marca 2018 13:28:09 CET Richard Duivenvoorde pisze:
> On 02-03-18 13:08, David Marteau wrote:
> > Hi
> > 
> > I stumbled on this post:
> > http://osgeo-org.1560.x6.nabble.com/A-pipinstall-plugin-is-possible-First
> > -What-s-the-difference-between-the-Osgeo4w-Shell-td5107633.html
> > 
> > What it the status of the problem of plugin dependency  for Qgis3 ?
> > Is there anything done so far ?
> 
> Nope.
> 
> We had a (private) discussion about it during latest hackfest, and Borys
> (in bcc) hopes to be able to address this as part of the plugins install
> overhaul.
> 
> As the discussion (2014?), you are pointing to, mentions pip and virtual
> env's: just yesterday I stumbled upon pipenv [0][1]. Not sure if that
> could be helpful, but apparently it is  a pip-virtualenv marriage...
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> Ps, maybe good to start a QEP [2] to discuss this?
> 
> [0] https://pipenv.readthedocs.io/en/latest/
> [1] http://docs.python-guide.org/en/latest/dev/virtualenvs/
> [2] https://github.com/qgis/QGIS-Enhancement-Proposals
> ___
> 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] Qgis 3.0 plugin dependencies status

[David Marteau]

+1 for a QEP on this matter

> Le 2 mars 2018 à 13:28, Richard Duivenvoorde  a écrit :
> 
> On 02-03-18 13:08, David Marteau wrote:
>> Hi
>> 
>> I stumbled on this post: 
>> http://osgeo-org.1560.x6.nabble.com/A-pipinstall-plugin-is-possible-First-What-s-the-difference-between-the-Osgeo4w-Shell-td5107633.html
>> 
>> What it the status of the problem of plugin dependency  for Qgis3 ? 
>> Is there anything done so far ? 
> 
> Nope.
> 
> We had a (private) discussion about it during latest hackfest, and Borys
> (in bcc) hopes to be able to address this as part of the plugins install
> overhaul.
> 
> As the discussion (2014?), you are pointing to, mentions pip and virtual
> env's: just yesterday I stumbled upon pipenv [0][1]. Not sure if that
> could be helpful, but apparently it is  a pip-virtualenv marriage...
> 
> Regards,
> 
> Richard Duivenvoorde
> 
> Ps, maybe good to start a QEP [2] to discuss this?
> 
> [0] https://pipenv.readthedocs.io/en/latest/
> [1] http://docs.python-guide.org/en/latest/dev/virtualenvs/
> [2] https://github.com/qgis/QGIS-Enhancement-Proposals

___
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 3.0 plugin dependencies status

[Richard Duivenvoorde]

On 02-03-18 13:08, David Marteau wrote:
> Hi
> 
> I stumbled on this post: 
> http://osgeo-org.1560.x6.nabble.com/A-pipinstall-plugin-is-possible-First-What-s-the-difference-between-the-Osgeo4w-Shell-td5107633.html
> 
> What it the status of the problem of plugin dependency  for Qgis3 ? 
> Is there anything done so far ? 

Nope.

We had a (private) discussion about it during latest hackfest, and Borys
(in bcc) hopes to be able to address this as part of the plugins install
overhaul.

As the discussion (2014?), you are pointing to, mentions pip and virtual
env's: just yesterday I stumbled upon pipenv [0][1]. Not sure if that
could be helpful, but apparently it is  a pip-virtualenv marriage...

Regards,

Richard Duivenvoorde

Ps, maybe good to start a QEP [2] to discuss this?

[0] https://pipenv.readthedocs.io/en/latest/
[1] http://docs.python-guide.org/en/latest/dev/virtualenvs/
[2] https://github.com/qgis/QGIS-Enhancement-Proposals
___
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] Qgis 3.0 plugin dependencies status

[David Marteau]

Hi

I stumbled on this post: 
http://osgeo-org.1560.x6.nabble.com/A-pipinstall-plugin-is-possible-First-What-s-the-difference-between-the-Osgeo4w-Shell-td5107633.html

What it the status of the problem of plugin dependency  for Qgis3 ? 
Is there anything done so far ? 

Thx
David

___
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 3.0 Sluggish on MacOS 10.13 with Retina Display

[Jeremy Palmer]

Hi Nyall,

On Wed, Feb 21, 2018 at 6:51 PM, Nyall Dawson 
wrote:
>
>
> I'm just saying that there's nothing QGIS specific there - so there's
> no clues there wherever it's a generic Qt issue or a QGIS regression.
>

I'm using xcode's instruments, but I've never really developed in any code
on MacOSX before. I will see what else can be dumped.


>
> I'm not familiar with OSX - can you set the monitor resolution
> manually? something like 1280 x 800 would be a good test.


I set the screen scale to 1280 x 800. It made some improvement in speed,
but QGIS 3.0 still is running much slower than 2.18.

I also tried enabling the Low Resolution mode for the app bundle as per
[1]. This setting forces the device pixel ratio to 1 from 2 for HiDPI
supported applications. e.g
qgis.utils.iface.mainWindow().devicePixelRatio() = 1. This of course forces
the UI to low resolution and reverses all of the QGIS 3.0 SVG icons work :( The
results were:

1. The QGIS 3.0 mapcanvas UI interactions seemed smoother due to the
increased frame-rate for redrawing the zoom rubberband box or moving the
the cursor.
2. But, the canvas redraws were still just and slow as a device pixel ratio
of 1. i.e The profiling still showed the same amount of CPU time

Here's the results of my benchmarking:

[image: Inline image 1]

Note: canvas size was determined using qgis.utils.iface.mapCanvas().size()

Before I proceed with further profiling it would be good to know if other
mac developers also see performance slowdowns like I do?

Cheers,
Jeremy

* [1] https://support.apple.com/en-nz/HT202471
___
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 3.0 Sluggish on MacOS 10.13 with Retina Display

[Nyall Dawson]

On 21 February 2018 at 07:31, Jeremy Palmer  wrote:
> Hi Nyall,
>
> On 21/02/2018 10:12, "Nyall Dawson"  wrote:
>
> There's not much to go on in that stack - it's all Qt internals.
>
>
> What would you like to see?

I'm just saying that there's nothing QGIS specific there - so there's
no clues there wherever it's a generic Qt issue or a QGIS regression.

> Are you sure this isn't solely due to the fact that QGIS is painting
> so many more pixels? I'd like to see a test where you force a low dpi
> resolution for both 2.18 and 3.0.
>
>
> What would be the best way to force low dpi?

I'm not familiar with OSX - can you set the monitor resolution
manually? something like 1280 x 800 would be a good test.

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] QGIS 3.0 Sluggish on MacOS 10.13 with Retina Display

[Jeremy Palmer]

Hi Nyall,

On 21/02/2018 10:12, "Nyall Dawson"  wrote:

There's not much to go on in that stack - it's all Qt internals.


What would you like to see?


Are you sure this isn't solely due to the fact that QGIS is painting
so many more pixels? I'd like to see a test where you force a low dpi
resolution for both 2.18 and 3.0.


What would be the best way to force low dpi?

Thanks
Jeremy
___
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 3.0 Sluggish on MacOS 10.13 with Retina Display

[Nyall Dawson]

On 21 February 2018 at 06:34, Jeremy Palmer  wrote:
> Hi All,
>
> For some time I've been noticing that QGIS 3.0 on MacOSX has sluggish canvas
> redraw speeds. When comparing between QGIS 2.18 and 3.0 I see ~4x more CPU
> activity in 3.0 when performing the same set of operations on the same
> dataset.
>
> My test case was using a single raster VRT with overviews, and zooming in
> and panning around the map cavnas for 20 sec. On average each time I tested
> this case the total used CPU time for 2.18 was about 6 secs, but in
> 3.0dev-64369f8099 (complied against QT 5.10.0 with homebrew) I get total CPU
> time of 25 secs. In QGIS 3.0 most of the time the application is using 100%
> CPU (one core) and spikes to about 180-200% CPU when the canvas redraws are
> performed. When using a profiler it seems much of the time is taken up in
> QImage::copy(QRect const&) within two seperate, but equivalent, call
> subtrees. See [1] for more info.

There's not much to go on in that stack - it's all Qt internals.

Are you sure this isn't solely due to the fact that QGIS is painting
so many more pixels? I'd like to see a test where you force a low dpi
resolution for both 2.18 and 3.0.

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] QGIS 3.0 Sluggish on MacOS 10.13 with Retina Display

[Jeremy Palmer]

Hi All,

For some time I've been noticing that QGIS 3.0 on MacOSX has sluggish
canvas redraw speeds. When comparing between QGIS 2.18 and 3.0 I see ~4x
more CPU activity in 3.0 when performing the same set of operations on the
same dataset.

My test case was using a single raster VRT with overviews, and zooming in
and panning around the map cavnas for 20 sec. On average each time I tested
this case the total used CPU time for 2.18 was about 6 secs, but in
3.0dev-64369f8099 (complied against QT 5.10.0 with homebrew) I get total
CPU time of 25 secs. In QGIS 3.0 most of the time the application is using
100% CPU (one core) and spikes to about 180-200% CPU when the canvas
redraws are performed. When using a profiler it seems much of the time is
taken up in QImage::copy(QRect const&) within two seperate, but equivalent,
call subtrees. See [1] for more info.

Is anyone else seeing slow map canvas performance in QGIS 3.0 on MacOSX?

Cheers,
Jeremy

[1]  - https://imgur.com/a/ZSRTf
___
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] QGIS 3.0 Processing plugin - handling multiple outputs

[Luke]

I'm updating my QGIS processing plugin algorithm from 2x - 3x.  The algorithm
generates and outputs one to many rasters. The number of output rasters is
unknown until the algorithm is run and depends on the input parameters.

In my QGIS 2x version, I just set a processing.core.outputs.OutputDirectory,
dumped all the rasters in there and then added them to the map using the
QgsMapLayerRegistry.instance().addMapLayer method.  A bit dodgy, but the 2x
version was just a quick proof of concept.

Is there a recommended approach for QGIS 3x in the processing framework to
handle an unknown number of outputs?  Or should I just  do something similar
to my 2x version, set a
QgsProcessingParameterFolderDestination/QgsProcessingOutputFolder and add
them to the map via QgsProject.instance().addMapLayer?


Regards
Luke



--
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] QGIS 3.0 Soft Feature Freeze

[Andreas Neumann]

Hi Tim,


The bug fixing programme already started - I believe there are still 
funds to support bug fixing so those interested should register with 
Andreas (who can also confirm if there are still funds available). 
Agreed it will be good to step it up over this month as we ramp up to 
release.


yes - and we already spent approx. 2/3 of our dedicated 3.0 bug fixing 
funds (including some expected pending invoices which I should receive 
in the next couple days). See also 
https://docs.google.com/spreadsheets/d/1F6v4g8Ayb3wIt73rxFKD8h4B95MaTwt-eDit8YvReB0/edit?usp=sharing 
for what was done regarding the paid bug fixing programme.


Funds are not unlimited, unfortunately, so if you want to work on behalf 
of this bug fixing initiative, please contact me upfront to check if 
funds are still available. I am going to publish the financial report 
next week - it is almost finished. Still waiting for some invoices from 
work done last year.





* we do not release with severe AND prominent known issue


Sure if it is corrupting your data or what have you it should be held 
back.


crashes are just as bad as one usually looses project configuration 
during the crash.




* we have a shorter dot release cycle (maybe once a week or switch to 
nightly builds) to avoid waiting too long for fixes


-1 from me for this. I think this is really going to screw around with 
Jürgen’s workflow - lets try to minimise churn and just slot into the 
standard workflows as much as possible.


I agree. Better stick with Jürgens schedule. I think our releases are 
already often enough. Besides for those who really need them there are 
nightly and weeklies. No need for extra releases.


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] QGIS 3.0 Soft Feature Freeze

[Tim Sutton]

Hi

> On 03 Jan 2018, at 02:34, Denis Rouzaud  wrote:
> 
> 
> 
> 
> Ok, let me re-word option 2 as:
> 
> "2. Carefully manage release expectations, with detailed explanations
> of known issues and regressions in the release notes. Stress in press
> releases/release notes that 3.0 is a new major release and that the
> QGIS team do not consider it a suitable replacement for the current
> stable LTR release, and that it is highly recommended that
> organisations do not replace their existing QGIS 2.x installations
> before careful in-house testing and evaluation of its suitability for
> their workplace. The next stable LTR QGIS release will be QGIS 3.2."
> 
> I agree on release asap knowing it might not be the most stable release ever.
> But, I would make sure
> * we have a serious effort on bugfixing prior to the release and following it

The bug fixing programme already started - I believe there are still funds to 
support bug fixing so those interested should register with Andreas (who can 
also confirm if there are still funds available). Agreed it will be good to 
step it up over this month as we ramp up to release.


> * we do not release with severe AND prominent known issue

Sure if it is corrupting your data or what have you it should be held back.


> * we have a shorter dot release cycle (maybe once a week or switch to nightly 
> builds) to avoid waiting too long for fixes

-1 from me for this. I think this is really going to screw around with Jürgen’s 
workflow - lets try to minimise churn and just slot into the standard workflows 
as much as possible.

Regards

Tim



> 
> Best regards,
> Denis
>  

—







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

___
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 3.0 Soft Feature Freeze

[Mathieu Pellerin]

I'm -1 to label 3.0 a "beta" product. I'd argue that in many respects, 3.0
is a more stable and reliable product than 2.18.

On Wed, Jan 3, 2018 at 10:14 AM, Bernd Vogelgesang  wrote:

> Am 02.01.2018, 23:39 Uhr, schrieb Nyall Dawson :
>
>
>
>>> I think on balance I prefer option #2 as it will get more people using
>>> QGIS 3 - we must just be careful to tell people that it is ‘next-gen’ and
>>> that the LTR is still 2.18….
>>>
>>
>> Ok, let me re-word option 2 as:
>>
>> "2. Carefully manage release expectations, with detailed explanations
>> of known issues and regressions in the release notes. Stress in press
>> releases/release notes that 3.0 is a new major release and that the
>> QGIS team do not consider it a suitable replacement for the current
>> stable LTR release, and that it is highly recommended that
>> organisations do not replace their existing QGIS 2.x installations
>> before careful in-house testing and evaluation of its suitability for
>> their workplace. The next stable LTR QGIS release will be QGIS 3.2."
>>
>> Nyall
>>
>
> 
>
> I like all your elaborated wordings, but couldn't you just brand 3.0 with
> a huge red BETA mark, and nearly everyone should know what this means:
> Evaluation: Yes!, Production: Maybe, on yout own risk.
>
> 
>
> ___
>> 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
>>
>
>
> --
> Bernd Vogelgesang
> Siedlerstraße 2
> 91083 Baiersdorf/Igelsdorf
> Tel: 09133-825374
>
> ___
> 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] QGIS 3.0 Soft Feature Freeze

[Bernd Vogelgesang]

Am 02.01.2018, 23:39 Uhr, schrieb Nyall Dawson :




I think on balance I prefer option #2 as it will get more people using  
QGIS 3 - we must just be careful to tell people that it is ‘next-gen’  
and that the LTR is still 2.18….


Ok, let me re-word option 2 as:

"2. Carefully manage release expectations, with detailed explanations
of known issues and regressions in the release notes. Stress in press
releases/release notes that 3.0 is a new major release and that the
QGIS team do not consider it a suitable replacement for the current
stable LTR release, and that it is highly recommended that
organisations do not replace their existing QGIS 2.x installations
before careful in-house testing and evaluation of its suitability for
their workplace. The next stable LTR QGIS release will be QGIS 3.2."

Nyall




I like all your elaborated wordings, but couldn't you just brand 3.0 with  
a huge red BETA mark, and nearly everyone should know what this means:  
Evaluation: Yes!, Production: Maybe, on yout own risk.





___
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



--
Bernd Vogelgesang
Siedlerstraße 2
91083 Baiersdorf/Igelsdorf
Tel: 09133-825374
___
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 3.0 Soft Feature Freeze

[Denis Rouzaud]

>
>
>
>
> Ok, let me re-word option 2 as:
>
> "2. Carefully manage release expectations, with detailed explanations
> of known issues and regressions in the release notes. Stress in press
> releases/release notes that 3.0 is a new major release and that the
> QGIS team do not consider it a suitable replacement for the current
> stable LTR release, and that it is highly recommended that
> organisations do not replace their existing QGIS 2.x installations
> before careful in-house testing and evaluation of its suitability for
> their workplace. The next stable LTR QGIS release will be QGIS 3.2."
>

I agree on release asap knowing it might not be the most stable release
ever.
But, I would make sure
* we have a serious effort on bugfixing prior to the release and following
it
* we do not release with severe AND prominent known issue
* we have a shorter dot release cycle (maybe once a week or switch to
nightly builds) to avoid waiting too long for fixes

Best regards,
Denis
___
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 3.0 Soft Feature Freeze

[Paolo Cavallini]

Fully agreed, both with the general meaning and with the wording.
Thanks.

Il 2 gennaio 2018 23:39:17 CET, Nyall Dawson  ha 
scritto:
>On 3 January 2018 at 06:51, Tim Sutton  wrote:
>>
>> Hi
>>
>> On 02 Jan 2018, at 12:16, Nyall Dawson 
>wrote:
>>
>> On 2 January 2018 at 19:54, Mathieu Pellerin 
>wrote:
>>
>>
>> +1 to set a release date for the last week of January. That'll give
>us 2 weeks of freeze period (assuming the vote turns out not to extend
>the soft freeze) which can be used to focus on fixes only. The soft
>freeze period saw a nice set of fixes too, which was nice.
>>
>>
>> I'm in favour of hard freezing this time (assuming we can get those
>> last couple of PRs reviewed quickly and merged).
>>
>> But I'm against setting a hard deadline for the final release yet.
>> That said truth is that IMO 3.0 still feels very buggy, and there's
>> lots of open high priority regressions against it. I think we've got
>> two options:
>>
>> 1. Move to a regular "are we ready for final release?" vote
>>
>> or
>>
>> 2. Just decide that 3.0.0 will have bugs, and that we should "release
>> early, release often" and hope that we stabilise things quickly for
>>
>> 3.0.1/3.0.2/…
>>
>>
>>
>> I think on balance I prefer option #2 as it will get more people
>using QGIS 3 - we must just be careful to tell people that it is
>‘next-gen’ and that the LTR is still 2.18….
>
>Ok, let me re-word option 2 as:
>
>"2. Carefully manage release expectations, with detailed explanations
>of known issues and regressions in the release notes. Stress in press
>releases/release notes that 3.0 is a new major release and that the
>QGIS team do not consider it a suitable replacement for the current
>stable LTR release, and that it is highly recommended that
>organisations do not replace their existing QGIS 2.x installations
>before careful in-house testing and evaluation of its suitability for
>their workplace. The next stable LTR QGIS release will be QGIS 3.2."
>
>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

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
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 3.0 Soft Feature Freeze

[Nyall Dawson]

On 3 January 2018 at 06:51, Tim Sutton  wrote:
>
> Hi
>
> On 02 Jan 2018, at 12:16, Nyall Dawson  wrote:
>
> On 2 January 2018 at 19:54, Mathieu Pellerin  wrote:
>
>
> +1 to set a release date for the last week of January. That'll give us 2 
> weeks of freeze period (assuming the vote turns out not to extend the soft 
> freeze) which can be used to focus on fixes only. The soft freeze period saw 
> a nice set of fixes too, which was nice.
>
>
> I'm in favour of hard freezing this time (assuming we can get those
> last couple of PRs reviewed quickly and merged).
>
> But I'm against setting a hard deadline for the final release yet.
> That said truth is that IMO 3.0 still feels very buggy, and there's
> lots of open high priority regressions against it. I think we've got
> two options:
>
> 1. Move to a regular "are we ready for final release?" vote
>
> or
>
> 2. Just decide that 3.0.0 will have bugs, and that we should "release
> early, release often" and hope that we stabilise things quickly for
>
> 3.0.1/3.0.2/…
>
>
>
> I think on balance I prefer option #2 as it will get more people using QGIS 3 
> - we must just be careful to tell people that it is ‘next-gen’ and that the 
> LTR is still 2.18….

Ok, let me re-word option 2 as:

"2. Carefully manage release expectations, with detailed explanations
of known issues and regressions in the release notes. Stress in press
releases/release notes that 3.0 is a new major release and that the
QGIS team do not consider it a suitable replacement for the current
stable LTR release, and that it is highly recommended that
organisations do not replace their existing QGIS 2.x installations
before careful in-house testing and evaluation of its suitability for
their workplace. The next stable LTR QGIS release will be QGIS 3.2."

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] QGIS 3.0 Soft Feature Freeze

[James Shaeffer]

Not a major contributor by any means, but I agree with Tim on this.

James Shaeffer

> I think on balance I prefer option #2 as it will get more people using QGIS 3 
> - we must just be careful to tell people that it is ‘next-gen’ and that the 
> LTR is still 2.18….
>
>Regards
>
>Tim

___
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 3.0 Soft Feature Freeze

[Tim Sutton]

Hi

> On 02 Jan 2018, at 12:16, Nyall Dawson  wrote:
> 
> On 2 January 2018 at 19:54, Mathieu Pellerin  wrote:
>> 
>> +1 to set a release date for the last week of January. That'll give us 2 
>> weeks of freeze period (assuming the vote turns out not to extend the soft 
>> freeze) which can be used to focus on fixes only. The soft freeze period saw 
>> a nice set of fixes too, which was nice.
>> 
> 
> I'm in favour of hard freezing this time (assuming we can get those
> last couple of PRs reviewed quickly and merged).
> 
> But I'm against setting a hard deadline for the final release yet.
> That said truth is that IMO 3.0 still feels very buggy, and there's
> lots of open high priority regressions against it. I think we've got
> two options:
> 
> 1. Move to a regular "are we ready for final release?" vote
> 
> or
> 
> 2. Just decide that 3.0.0 will have bugs, and that we should "release
> early, release often" and hope that we stabilise things quickly for
> 3.0.1/3.0.2/…


I think on balance I prefer option #2 as it will get more people using QGIS 3 - 
we must just be careful to tell people that it is ‘next-gen’ and that the LTR 
is still 2.18….

Regards

Tim

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

—







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

___
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 3.0 Soft Feature Freeze

[Luigi Pirelli]

+1 for freeze and more bug fix... I've report about processing regresións

On Tuesday, 2 January 2018, Nyall Dawson  wrote:

> On 2 January 2018 at 19:54, Mathieu Pellerin  wrote:
> >
> > +1 to set a release date for the last week of January. That'll give us 2
> weeks of freeze period (assuming the vote turns out not to extend the soft
> freeze) which can be used to focus on fixes only. The soft freeze period
> saw a nice set of fixes too, which was nice.
> >
>
> I'm in favour of hard freezing this time (assuming we can get those
> last couple of PRs reviewed quickly and merged).
>
> But I'm against setting a hard deadline for the final release yet.
> That said truth is that IMO 3.0 still feels very buggy, and there's
> lots of open high priority regressions against it. I think we've got
> two options:
>
> 1. Move to a regular "are we ready for final release?" vote
>
> or
>
> 2. Just decide that 3.0.0 will have bugs, and that we should "release
> early, release often" and hope that we stabilise things quickly for
> 3.0.1/3.0.2/...
>
> 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



-- 
Luigi Pirelli

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

[Nyall Dawson]

On 2 January 2018 at 19:54, Mathieu Pellerin  wrote:
>
> +1 to set a release date for the last week of January. That'll give us 2 
> weeks of freeze period (assuming the vote turns out not to extend the soft 
> freeze) which can be used to focus on fixes only. The soft freeze period saw 
> a nice set of fixes too, which was nice.
>

I'm in favour of hard freezing this time (assuming we can get those
last couple of PRs reviewed quickly and merged).

But I'm against setting a hard deadline for the final release yet.
That said truth is that IMO 3.0 still feels very buggy, and there's
lots of open high priority regressions against it. I think we've got
two options:

1. Move to a regular "are we ready for final release?" vote

or

2. Just decide that 3.0.0 will have bugs, and that we should "release
early, release often" and hope that we stabilise things quickly for
3.0.1/3.0.2/...

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] QGIS 3.0 Soft Feature Freeze

[Mathieu Pellerin]

+1 to set a release date for the last week of January. That'll give us 2
weeks of freeze period (assuming the vote turns out not to extend the soft
freeze) which can be used to focus on fixes only. The soft freeze period
saw a nice set of fixes too, which was nice.



On Tue, Jan 2, 2018 at 4:48 PM, Nathan Woodrow  wrote:

> I think we really need some more bug fixing time.  I noticed all the
> layouts stuff from Nyall is now there but given the large amount of work
> more time would be good IMO.
>
> - Nathan
>
> On Tue, Jan 2, 2018 at 7:45 PM, Tim Sutton  wrote:
>
>> Hi
>>
>> For my part I think we can go ahead and set a date for the freeze (e.g.
>> Friday) - Etienne still needs to commit the last metadata serialisation
>> stuff but he has kindly come back from leave for a day to finish that.
>> Stephané wanted to merge the OGC filters stuff which is fine for me.
>>
>> Do we want  have some additional bug fix only time before we make the
>> actual release - perhaps targeting the release for the end of Jan? I
>> haven't looked in detail what blocking issues there are but from Mac point
>> of view the GRASS processing tools still don’t work which is a bit of a
>> blocker IMHO.
>>
>> Regards
>>
>> Tim
>>
>>
>> On 02 Jan 2018, at 11:31, Paolo Cavallini  wrote:
>>
>> Hi all,
>> for the first time, a good part of developers are uncertain about the
>> need to postpone the freeze. IMHO it is better to discuss about his in
>> the list. From my point of view, we should postpone it only if there is
>> a real, strong necessity, which does not seem the case now.
>> Opinions?
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> 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
>>
>>
>> ___
>> 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] QGIS 3.0 Soft Feature Freeze

[Nathan Woodrow]

I think we really need some more bug fixing time.  I noticed all the
layouts stuff from Nyall is now there but given the large amount of work
more time would be good IMO.

- Nathan

On Tue, Jan 2, 2018 at 7:45 PM, Tim Sutton  wrote:

> Hi
>
> For my part I think we can go ahead and set a date for the freeze (e.g.
> Friday) - Etienne still needs to commit the last metadata serialisation
> stuff but he has kindly come back from leave for a day to finish that.
> Stephané wanted to merge the OGC filters stuff which is fine for me.
>
> Do we want  have some additional bug fix only time before we make the
> actual release - perhaps targeting the release for the end of Jan? I
> haven't looked in detail what blocking issues there are but from Mac point
> of view the GRASS processing tools still don’t work which is a bit of a
> blocker IMHO.
>
> Regards
>
> Tim
>
>
> On 02 Jan 2018, at 11:31, Paolo Cavallini  wrote:
>
> Hi all,
> for the first time, a good part of developers are uncertain about the
> need to postpone the freeze. IMHO it is better to discuss about his in
> the list. From my point of view, we should postpone it only if there is
> a real, strong necessity, which does not seem the case now.
> Opinions?
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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
>
>
> ___
> 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] QGIS 3.0 Soft Feature Freeze

[Tim Sutton]

Hi

For my part I think we can go ahead and set a date for the freeze (e.g. Friday) 
- Etienne still needs to commit the last metadata serialisation stuff but he 
has kindly come back from leave for a day to finish that. Stephané wanted to 
merge the OGC filters stuff which is fine for me. 

Do we want  have some additional bug fix only time before we make the actual 
release - perhaps targeting the release for the end of Jan? I haven't looked in 
detail what blocking issues there are but from Mac point of view the GRASS 
processing tools still don’t work which is a bit of a blocker IMHO.

Regards

Tim

> On 02 Jan 2018, at 11:31, Paolo Cavallini  wrote:
> 
> Hi all,
> for the first time, a good part of developers are uncertain about the
> need to postpone the freeze. IMHO it is better to discuss about his in
> the list. From my point of view, we should postpone it only if there is
> a real, strong necessity, which does not seem the case now.
> Opinions?
> All the best.
> -- 
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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

___
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] QGIS 3.0 Soft Feature Freeze

[Paolo Cavallini]

Hi all,
for the first time, a good part of developers are uncertain about the
need to postpone the freeze. IMHO it is better to discuss about his in
the list. From my point of view, we should postpone it only if there is
a real, strong necessity, which does not seem the case now.
Opinions?
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
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 3.0 beta

[Rainer Hurling]

Am 08.07.2017 um 10:13 schrieb Matthias Kuhn:

Hi all,

Not too far away we will enter feature freeze for QGIS 3.0 and will be
trying to polish the next release as much as possible.

During this time, a lot of testing will need to be done in order to be
able to best spend the bugfixing time. There are a handful of people who
regularly test nightlies and report bugs (thanks!).

I wonder if it's possible to attract more testers for the next release
by providing a "beta".

I think releasing a version labelled "beta" at the beginning of the
feature freeze (and another one half way through) will make more people
aware of the upcoming release. This can lead to additional important
testing from audience which otherwise would only "test" the final
release (with a lower acceptance of bugs). Besides that, I think it will
also be a good signal for devs to start porting plugin code and a very
good preparation for end users marketing-wise.

It will be best served with a blog post explaining how critical the
bugfixing phase is for a release and how resources for this are allocated.

It's just an idea I had in mind for some time. Does anyone dislike it?

Thanks
Matthias


Many thanks for all the work on the upcoming 3.0 version. Really 
appreciated.


As the maintainer of the port for the FreeBSD operating system [1], I am 
in the process of preparing all dependencies for the 3.0 version. Some 
of the needed QT5 and Python3 deps are not present or usable on FreeBSD 
until now. We had good experiences with using 2.x.x versions of QGIS on 
FreeBSD :)


Here my question to the QGIS devs: Is there a (roughly complete) list of 
facultative and optional dependencies and their versions to build and 
run a QGIS 3.0 (beta) on Unix-alike systems? And also, is there a 
(commented) list of options, one can enable/disable at build time?


Any hint or help is really appreciated.

Thanks in advance and greetings from Göttingen in Germany,
Rainer Hurling


[1] http://www.freshports.org/graphics/qgis
___
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] QGIS 3.0 binaries for MacOS

[EMTB prywatne]

Is it possible to find QGIS 3.0 development builds as binaries for MacOS (like 
it used to be on http://qgis.dakotacarto.com)? I would like to try and give you 
feedback about new version of QGIS but building from source is to much time 
consuming to incorporate it in my workflow.

Regards
___
Michał Jurewicz
tel. 517 752 328
e-mail: mala...@emtb.pl

___
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 3.0 beta

[Tim Sutton]

Hi


I would lean towards -1 for a beta - we have had this same debate numerous
times before and tried using beta's before. I don't think a beta will
substantially increase testing uptake and it has the rather bad side effect
that people will be using old code as their reference point (as opposed to
using the nightly builds where they can see the latest fixes at any time).

I'm happy to keep quiet if others think it is worth doing...

Regards

Tim

On Sat, Jul 8, 2017 at 6:50 PM, Jürgen E. Fischer  wrote:

> Hi Richard,
>
> On Sat, 08. Jul 2017 at 12:43:48 +0200, Richard Duivenvoorde wrote:
> > Just for clarity, there IS already a possibility to test/view current
> > master (3.0 development version == 2.99) for Windows users:
> >
> > Either download the latest weekly 2.99 standalone installer from:
> > http://qgis.org/downloads/weekly/
> >
> > OR use
> >
> > OSGeo4W package manager and install the "qgis-dev: QGIS nightly build of
> > the development branch"
>
> OR qgis-full-dev which also depends on a bunch of additional useful
> packages.
>
> > AND to see the most info, ALSO install "qgis-dev-pdb: Debugging symbols
> > for QGIS nightly build of the development branch"
>
> AND now alos on qgis-dev-pdb.   PLUS qgis-full-dev is the base of the
> weekly
> NSIS package.
>
>
> 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
>
> ___
> 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
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
Tim is a member of the QGIS Project Steering Committee
---
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] QGIS 3.0 beta

[Jürgen E . Fischer]

Hi Richard,

On Sat, 08. Jul 2017 at 12:43:48 +0200, Richard Duivenvoorde wrote:
> Just for clarity, there IS already a possibility to test/view current
> master (3.0 development version == 2.99) for Windows users:
> 
> Either download the latest weekly 2.99 standalone installer from:
> http://qgis.org/downloads/weekly/
> 
> OR use
> 
> OSGeo4W package manager and install the "qgis-dev: QGIS nightly build of
> the development branch"

OR qgis-full-dev which also depends on a bunch of additional useful packages.

> AND to see the most info, ALSO install "qgis-dev-pdb: Debugging symbols
> for QGIS nightly build of the development branch"

AND now alos on qgis-dev-pdb.   PLUS qgis-full-dev is the base of the weekly
NSIS package.


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 3.0 beta

[Richard Duivenvoorde]

On 08-07-17 11:48, Wondimagegn Tesfaye wrote:
> Dear Mattias, 
> 
> Thank you for the hard work! This is a good approach. Starting to
> testing the beta before the feature freeze is good to incorporate more
> feedback from the users and developers.

Just for clarity, there IS already a possibility to test/view current
master (3.0 development version == 2.99) for Windows users:

Either download the latest weekly 2.99 standalone installer from:
http://qgis.org/downloads/weekly/

OR use

OSGeo4W package manager and install the "qgis-dev: QGIS nightly build of
the development branch"
AND to see the most info, ALSO install "qgis-dev-pdb: Debugging symbols
for QGIS nightly build of the development branch"

___
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 3.0 beta

[Wondimagegn Tesfaye]

Dear Mattias,

Thank you for the hard work! This is a good approach. Starting to testing
the beta before the feature freeze is good to incorporate more feedback
from the users and developers.

Regards,
Wondimagegn

On Jul 8, 2017 11:13, "Matthias Kuhn"  wrote:

> Hi all,
>
> Not too far away we will enter feature freeze for QGIS 3.0 and will be
> trying to polish the next release as much as possible.
>
> During this time, a lot of testing will need to be done in order to be
> able to best spend the bugfixing time. There are a handful of people who
> regularly test nightlies and report bugs (thanks!).
>
> I wonder if it's possible to attract more testers for the next release
> by providing a "beta".
>
> I think releasing a version labelled "beta" at the beginning of the
> feature freeze (and another one half way through) will make more people
> aware of the upcoming release. This can lead to additional important
> testing from audience which otherwise would only "test" the final
> release (with a lower acceptance of bugs). Besides that, I think it will
> also be a good signal for devs to start porting plugin code and a very
> good preparation for end users marketing-wise.
>
> It will be best served with a blog post explaining how critical the
> bugfixing phase is for a release and how resources for this are allocated.
>
> It's just an idea I had in mind for some time. Does anyone dislike it?
>
> Thanks
> 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
___
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 3.0 beta

[Richard Duivenvoorde]

On 08-07-17 10:13, Matthias Kuhn wrote:
> Hi all,
> 
> Not too far away we will enter feature freeze for QGIS 3.0 and will be
> trying to polish the next release as much as possible.
> 
> During this time, a lot of testing will need to be done in order to be
> able to best spend the bugfixing time. There are a handful of people who
> regularly test nightlies and report bugs (thanks!).
> 
> I wonder if it's possible to attract more testers for the next release
> by providing a "beta".
> 
> I think releasing a version labelled "beta" at the beginning of the
> feature freeze (and another one half way through) will make more people
> aware of the upcoming release. This can lead to additional important
> testing from audience which otherwise would only "test" the final
> release (with a lower acceptance of bugs). Besides that, I think it will
> also be a good signal for devs to start porting plugin code and a very
> good preparation for end users marketing-wise.
> 
> It will be best served with a blog post explaining how critical the
> bugfixing phase is for a release and how resources for this are allocated.
> 
> It's just an idea I had in mind for some time. Does anyone dislike it?

Yep, I was thinking about something like this too: BUT there is always
the tension between willing to show and test a new version AND giving
the average user an as stable possible QGIS to work with.
So either work with some beta's OR consider 3.0 (and 3.2?) more or less
as versions which will have some growing pains? Though that is hard to
sell to the average user I think...

Other wild ideas:
- call 3.0 something like: Beta, Troje or Atlantis ;-)

And do a lot of communication that people should really test it in the
actual/real workflows to catch actual usability issues. But also... do
keep in mind that due to the changes in api's, code, Qt, Python etc etc
it is more likely that things will break or crash.

Yesterday I hit the first crash screen (on a Windows machine):

https://files.gitter.im/qgis/QGIS/kjUe/image.png
(ended up as https://issues.qgis.org/issues/16810 by the way)

Nice work, Nathan!

And looking at it, 3.0/beta should probably also have debug info so the
Stack Trace is as descriptive as possible?

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] QGIS 3.0 beta

[Matthias Kuhn]

Hi all,

Not too far away we will enter feature freeze for QGIS 3.0 and will be
trying to polish the next release as much as possible.

During this time, a lot of testing will need to be done in order to be
able to best spend the bugfixing time. There are a handful of people who
regularly test nightlies and report bugs (thanks!).

I wonder if it's possible to attract more testers for the next release
by providing a "beta".

I think releasing a version labelled "beta" at the beginning of the
feature freeze (and another one half way through) will make more people
aware of the upcoming release. This can lead to additional important
testing from audience which otherwise would only "test" the final
release (with a lower acceptance of bugs). Besides that, I think it will
also be a good signal for devs to start porting plugin code and a very
good preparation for end users marketing-wise.

It will be best served with a blog post explaining how critical the
bugfixing phase is for a release and how resources for this are allocated.

It's just an idea I had in mind for some time. Does anyone dislike it?

Thanks
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

[QGIS-Developer] QGIS 3.0 Error: module 'PyQt5.QtWidgets' has no attribute 'QgsDockWidget'

[C Hamilton]

I am attempting to switch from QDockWidget to QgsDockWidget with my Lat Lon
Tools plugin for QGIS 3.0. I am getting this error:

  File "C:\OSGEO4~1\apps\Python36\lib\site-packages\PyQt5\uic\__init__.py",
line 203, in loadUiType
return (ui_globals[winfo["uiclass"]], getattr(QtWidgets,
winfo["baseclass"]))
AttributeError: module 'PyQt5.QtWidgets' has no attribute 'QgsDockWidget'

Normally what I do when I encounter these types of errors is to change the
custom widget lines of code from something like:

 
  
   QgsDockWidget
   QDockWidget

*  qgsdockwidget.h*   1
  
 

to

 
  
   QgsDockWidget
   QDockWidget

*  qgis.gui*   1
  

This has always worked in the past, but it is not working for
QgsDockWidget. It still works for the other custom widgets. Is this a bug
or do I need to do something differently in my .ui code?

Thanks,

Calvin
___
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 3.0: Plans to support librttopo?

[Nyall Dawson]

On 7 March 2017 at 16:31, Mark Johnson  wrote:
>>> I'm confused - what is missing?
>
> The topic here is that when using MapUnits
> - where the MapUnits are degrees
> that a constant value (valid around the world) is not possible.
>
> If you set this to 5 (intended as meters on the map)
> - the further you zoom in, the circle will get bigger always showing an area
> of 5 meters
>
> If the Map is switched to WSG84
> - then you will get 5 degrees and not the desired area of 5 meters
> --> which for my area would be 0.75, at the equator 0,45 and in you
> area something different
>
> Since the source and destination crs are unknown when this attribute value
> is being set
> - one cannot assume that one or the other use meters and therefore cannot be
> used

It might be unknown at the time of setting that value - but it's
certainly known at the time that
QgsRenderContext::convertToPainterUnits or similar is called!

So you add a new QgsUnitTypes::RenderUnit enum value for
MapUnitMeters, and then if that unit is encountered by
QgsRenderContext::convertToPainterUnits you could do the calculation
from metres -> real map units -> painter units then. (The conversion
value could be cached in the render context to avoid multiple
coordinate transforms)

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] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

>> I'm confused - what is missing?

The topic here is that when using MapUnits
- where the MapUnits are degrees
that a constant value (valid around the world) is not possible.

If you set this to 5 (intended as meters on the map)
- the further you zoom in, the circle will get bigger always showing an
area of 5 meters

If the Map is switched to WSG84
- then you will get 5 degrees and not the desired area of 5 meters
--> which for my area would be 0.75, at the equator 0,45 and in you
area something different

Since the source and destination crs are unknown when this attribute value
is being set
- one cannot assume that one or the other use meters and therefore cannot
be used

Mark
___
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 3.0: Plans to support librttopo?

[Nyall Dawson]

On 7 March 2017 at 15:37, Mark Johnson  wrote:
>>> Everything you need should already be encapsulated in QgsRenderContext
>>> (and the QgsMapToPixel member).
>
> For everything but degrees it is.
> But in the case of degrees is is not
> - there the (incorrect) assumption is being made that the world is flat
> The value being used for DEGREE_TO_METER 111319.49079327358
> - is only valid on the Equator
> In my area a degree is around 6,7 meters
> - and this is the value needed
>
>>> This shouldn't be implemented using an external dependency
> I understand the reluctance to adding a further dependency, but GEOS is also
> used
> - and librttopo is an extension of GEOS
>
> Unfortunately there are not many degree based functions that allows the
> combination with a distance as meters.

I'm confused - what is missing? You have the extent, map scale, and
source and destination crs with their corresponding map units. What
more is needed?

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] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

>> Everything you need should already be encapsulated in QgsRenderContext
>> (and the QgsMapToPixel member).

For everything but degrees it is.
But in the case of degrees is is not
- there the (incorrect) assumption is being made that the world is flat
The value being used for DEGREE_TO_METER 111319.49079327358
- is only valid on the Equator
In my area a degree is around 6,7 meters
- and this is the value needed

>> This shouldn't be implemented using an external dependency
I understand the reluctance to adding a further dependency, but GEOS is
also used
- and librttopo is an extension of GEOS

Unfortunately there are not many degree based functions that allows the
combination with a distance as meters.

---
Looking at the code yesterday, the following could be a realistic
possiblity to implement this:

QgsMapRenderer:
- add double mMeterAsMapUnit [default 1.0 for meters distance unit]
QgsMapRenderer::setDestinationCrs
// before setExtent is called:
 
mMeterAsMapUnit=QgsUnitTypes::fromUnitToUnitFactor(QGis::Meters,crs.mapUnits());
mRenderContext.setMeterAsMapUnit( mMeterAsMapUnit ) ;

QgsMapRenderer::setExtent

  if ( mSettings.destinationCrs().isGeographic() )
  { // Retrieve realistic MapUnits for a meter based on result of
QgsMapCanvas::center()
   // meterAsMapUnit=
  }

QgsRenderContext
add:
/** 1 meter in Map-Unit*/
double mMeterAsMapUnit;
void setMeterAsMapUnit( double meterAsMapUnit ) {mMeterAsMapUnit =
meterAsMapUnit;}
double meterAsMapUnit() const {return mMeterAsMapUnit;}

QgsSymbolLayerV2Utils::convertToMapUnits:

  switch ( unit )
  {
case QgsSymbolV2::MetersUnit:
{ // Note: must fall through to QgsSymbolV2::MapUnit
 size=size*c.meterAsMapUnit();
}
case QgsSymbolV2::MapUnit:

I will try this out and see if it brings a reasonable result.

Mark Johnson, Berlin Germany
___
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 3.0: Plans to support librttopo?

[Nyall Dawson]

On 6 March 2017 at 23:45, Mark Johnson  wrote:
> The spatialite function 'ST_Project' is based on the librttopo functionality
> (formally LWGEOM)
> - and is only available when compiled with '--enable-rttopo'
>
> https://git.osgeo.org/gogs/rttopo/librttopo
>
> So if a support for 'Meters as Map units' was desired, in the case of
> degrees
> - the use the librttopo functionality as a part of the 'QgsGeos' would be
> the most effective way to deal with this
>
> This would be a new dependency, but would also offer many other
> functionalities (such as Topology).

Hi Mark,

This shouldn't be implemented using an external dependency -- instead
you'll need to use the existing QGIS classes like
QgsCoordinateTransform. You'd just need to modify:

QgsRenderContext::convertToPainterUnits
QgsRenderContext::convertToMapUnits
QgsRenderContext::convertFromMapUnits

Everything you need should already be encapsulated in QgsRenderContext
(and the QgsMapToPixel member).

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] QGIS 3.0: Plans to support librttopo?

[Mark Johnson]

The spatialite function 'ST_Project' is based on the librttopo functionality
(formally LWGEOM)
- and is only available when compiled with '--enable-rttopo'

https://git.osgeo.org/gogs/rttopo/librttopo

So if a support for 'Meters as Map units' was desired, in the case of
degrees
- the use the librttopo functionality as a part of the 'QgsGeos' would be
the most effective way to deal with this

This would be a new dependency, but would also offer many other
functionalities (such as Topology).

Mark Johnson, Berlin Germany
___
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] QGIS 3.0 API related issues

[Nyall Dawson]

Hi all,

A new Github issue tracker has been created (thanks Paolo!) to track
discussion relating to potential API changes in QGIS 3.0:

https://github.com/qgis/qgis3.0_api/issues

I'd encourage you to post your thoughts there so that we can start to
get a feel for the amount of work desired for the API break. This can
then be used to help gauge the timing required for the 3.0 release.

Note that this is for API related discussion only, not general feature
requests for QGIS 3.0!

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Marco Hugentobler]

Hi Nyall

- geometry rework, where an api break would result in a better
foundation moving forward

For the geometry rework, it is not a problem to keep compatibility with 
2. It is even an advantage, as there is more time to adapt the numerous 
pieces of code that work with QgsGeometry.


I think it is to early to go for version 3, 2 has been released a bit 
more than a year ago.


Regards,
Marco

On 08.11.2014 07:11, Nyall Dawson wrote:

Hi all,

I'm just wondering - given a few large changes coming up, including:
- qt5 support, possibly breaking plugins
- potential composer redesign, breaking api
- geometry rework, where an api break would result in a better
foundation moving forward

... is it worth exploring the idea of making the next release QGIS 3.0
and breaking API? I know the original plan was for 3.0 to coincide
with python 3 support, but that doesn't appear to be anywhere on the
horizon yet.

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Dr. Marco Hugentobler
Sourcepole -  Linux  Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Geodrinx]

Hello Nathan,

 Personally I think we should still do 2.8, LTR it, and then we can do 3.0 for 
 the next release. 
 
 Breaking the API again without a LTR in place makes me nervous as the 2.0 API 
 really wasn't that long ago.

+1000  for  LTS

I am with you:  please, stop to change the api. 
If we like new functions, please add them, without change old ones. 

Thank you

Roberto

 
 - Nathan
 
 On Sat Nov 08 2014 at 4:11:34 PM Nyall Dawson nyall.daw...@gmail.com wrote:
 Hi all,
 
 I'm just wondering - given a few large changes coming up, including:
 - qt5 support, possibly breaking plugins
 - potential composer redesign, breaking api
 - geometry rework, where an api break would result in a better
 foundation moving forward
 
 ... is it worth exploring the idea of making the next release QGIS 3.0
 and breaking API? I know the original plan was for 3.0 to coincide
 with python 3 support, but that doesn't appear to be anywhere on the
 horizon yet.
 
 Nyall
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Matthias Kuhn]

Hi

QGIS 3 should come with python 3. I don't think that python 3 can be a
smooth transition so this would require us to make QGIS 4 and break
plugins once again.

Qt5 support does not require QGIS 3.

Geometry and Composer(Layout) may need QGIS 3. But then we can as well
just introduce python 3 as well.

Matthias

On 08.11.2014 09:11, Geodrinx wrote:
 Hello Nathan,

 Personally I think we should still do 2.8, LTR it, and then we can do
 3.0 for the next release. 

 Breaking the API again without a LTR in place makes me nervous as the
 2.0 API really wasn't that long ago.

 +1000  for  LTS

 I am with you:  please, stop to change the api. 
 If we like new functions, please add them, without change old ones. 

 Thank you

 Roberto


 - Nathan

 On Sat Nov 08 2014 at 4:11:34 PM Nyall Dawson nyall.daw...@gmail.com
 mailto:nyall.daw...@gmail.com wrote:

 Hi all,

 I'm just wondering - given a few large changes coming up, including:
 - qt5 support, possibly breaking plugins
 - potential composer redesign, breaking api
 - geometry rework, where an api break would result in a better
 foundation moving forward

 ... is it worth exploring the idea of making the next release
 QGIS 3.0
 and breaking API? I know the original plan was for 3.0 to coincide
 with python 3 support, but that doesn't appear to be anywhere on the
 horizon yet.

 Nyall
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 mailto:Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Help getting QGIS to the next level of quality before November 15!
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 08/11/2014 09:42, Matthias Kuhn ha scritto:

 QGIS 3 should come with python 3. I don't think that python 3 can
 be a smooth transition so this would require us to make QGIS 4 and
 break plugins once again.
 
 Qt5 support does not require QGIS 3.
 
 Geometry and Composer(Layout) may need QGIS 3. But then we can as
 well just introduce python 3 as well.

I agree, LTS and reducing the number of breakages fit well together;
concentrating breakages (Qt5, Py3, layout, etc.) in a single release
seems a better option, especially for plugin developers.
All the best.
- -- 
Paolo Cavallini - www.faunalia.eu
QGIS  PostGIS courses: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRd2HMACgkQ/NedwLUzIr7b8QCfflPN99RK5BxENZGzS6H7A54Y
rMwAnjC8h8Vif+IPv1p7aXtX95ZirSIB
=FvGU
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Matthias Kuhn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Paolo,

Please don't list Qt5 in breakages.

Thank you
Matthias

On 08.11.2014 09:46, Paolo Cavallini wrote:
 Il 08/11/2014 09:42, Matthias Kuhn ha scritto:

  QGIS 3 should come with python 3. I don't think that python 3 can
  be a smooth transition so this would require us to make QGIS 4 and
  break plugins once again.

  Qt5 support does not require QGIS 3.

  Geometry and Composer(Layout) may need QGIS 3. But then we can as
  well just introduce python 3 as well.

 I agree, LTS and reducing the number of breakages fit well together;
 concentrating breakages (Qt5, Py3, layout, etc.) in a single release
 seems a better option, especially for plugin developers.
 All the best.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

- -- 
Help getting QGIS to the next level of quality before November 15!
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUXd8sAAoJEAnmVyKpy88LWb4IANOLwEjnpXVsJH9G5q2qo3s/
EWCQ2l5Ea3FmxADUiUoZVEU99OJqWdb/rKmKETMTyNU/6G0V8G3mSKYGTdJLzxhu
N0q5F768khcQOWjflHp1TfjE3+AIeZstiN5zLNhTjmYFLOFxPGnDZBlGCLvUyy4v
3t81y1jW0pQfuGoyLpD4jcC/Z2Mm9hty5mOGj1PmwZqLbU0dFyzTPko0K3B6MgXC
7dso4tgg68BwP8BKcsX2RUFkidj0jTPzgicTnxcUIkHzME+wq4FDbPezTZlBQyG6
CwxUuIzJ6hwgW2MLfiy+Vn25q1t8XpiFQxWgwQQfdwhUDDlxotgT0iAgWU+8oCc=
=tT7s
-END PGP SIGNATURE-

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Nyall Dawson]

On 08/11/2014 8:15 pm, Matthias Kuhn matthias.k...@gmx.ch wrote:


 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Paolo,

 Please don't list Qt5 in breakages.


Hi Matthias,

I'm a little confused - I was under the impression that some web related
classes had been removed from qt5 (hence the mention of a possible
breakage). Maybe I misinterpreted something.. If not, apologies for the
noise.

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Nathan Woodrow]

Also PyQt4 imports won't work anymore so that would be a break right?

On Sat, Nov 8, 2014, 7:52 PM Nyall Dawson nyall.daw...@gmail.com wrote:


 On 08/11/2014 8:15 pm, Matthias Kuhn matthias.k...@gmx.ch wrote:
 
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi Paolo,
 
  Please don't list Qt5 in breakages.
 

 Hi Matthias,

 I'm a little confused - I was under the impression that some web related
 classes had been removed from qt5 (hence the mention of a possible
 breakage). Maybe I misinterpreted something.. If not, apologies for the
 noise.

 Nyall
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Matthias Kuhn]

Hi,

The confusion comes from that there are two different things:

 * Qt5 compatibility
 * Qt5 binaries

The first one is a thing about the QGIS source code (qt5 branch).
The second one is about compiling/packaging.

The first step does not break anything. And allows to deprecate certain
features (e.g. qgshttptransaction) to allow for a smooth transition. It
is possible to write code that works with both versions.

The second step may actually break things. But that is not tied to a
version tag in our git repository but to a packagers decision.

*TL;DR:*

 *  Introducing Qt5 support in the QGIS source code does not break anything.
 *  Your distro actually shipping QGIS {2,3} compiled against Qt5 may
break stuff.

Matthias

On 08.11.2014 10:52, Nyall Dawson wrote:


 On 08/11/2014 8:15 pm, Matthias Kuhn matthias.k...@gmx.ch
 mailto:matthias.k...@gmx.ch wrote:
 
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Hi Paolo,
 
  Please don't list Qt5 in breakages.
 

 Hi Matthias,

 I'm a little confused - I was under the impression that some web
 related classes had been removed from qt5 (hence the mention of a
 possible breakage). Maybe I misinterpreted something.. If not,
 apologies for the noise.

 Nyall



-- 
Help getting QGIS to the next level of quality before November 15!
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Nyall Dawson]

On 08/11/2014 9:05 pm, Matthias Kuhn matthias.k...@gmx.ch wrote:


  *  Introducing Qt5 support in the QGIS source code does not break
anything.
  *  Your distro actually shipping QGIS {2,3} compiled against Qt5 may
 break stuff.


Makes sense now, thanks. However, by Debian removing Qt4, aren't we
effectively in a situation where users are going to have a qt api break
forced upon them, regardless of any decisions/actions we can make?

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Matthias Kuhn]

On 08.11.2014 11:22, Nyall Dawson wrote:


 On 08/11/2014 9:05 pm, Matthias Kuhn matthias.k...@gmx.ch
 mailto:matthias.k...@gmx.ch wrote:
 
 
   *  Introducing Qt5 support in the QGIS source code does not break
 anything.
   *  Your distro actually shipping QGIS {2,3} compiled against Qt5 may
  break stuff.
 

 Makes sense now, thanks. However, by Debian removing Qt4, aren't we
 effectively in a situation where users are going to have a qt api
 break forced upon them, regardless of any decisions/actions we can make?

 Nyall

In terms of project management it would probably be good to have a
recommended Qt version. To avoid the situation that certain users are
running the same version of QGIS with Qt4 others with Qt5 and therefore
some plugins work on one platform, some on others.

Debian seems to release at a rate of about 0.5/year, so we still have
more than 2 years to go before we are forced to release a Qt5 version
(we still may do it earlier if we like and we still could decide to have
a WITH_INTERNAL_QT4 CMake option ;) ).

Matthias

-- 
Help getting QGIS to the next level of quality before November 15!
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 08/11/2014 10:15, Matthias Kuhn ha scritto:

 Please don't list Qt5 in breakages.

sorry, maybe I misunderstood, but thought the plugins have to be
somewhat fixed.
All the best.
- -- 
Paolo Cavallini - www.faunalia.eu
QGIS  PostGIS courses: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRd9XgACgkQ/NedwLUzIr5tGwCgiJDGvbGtLJSK9c1xuFcDnDtv
/VYAniLAGRAskF8y9o7YclcNJyxA82KC
=ERyg
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Luca Manganelli]

On Sat, Nov 8, 2014 at 8:01 AM, Nathan Woodrow madman...@gmail.com wrote:
 Personally I think we should still do 2.8, LTR it, and then we can do 3.0
 for the next release.

I agree with a LTS version (what's LTR??? :-) ). It should be
important that the 2.X will not be abbandoned like as the last 1.X
series (1.8), with the Postgres primary key bug that remained UNFIXED
and that version was pretty useless...
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Anita Graser]

On Sat, Nov 8, 2014 at 8:01 AM, Nathan Woodrow madman...@gmail.com wrote:
 Personally I think we should still do 2.8, LTR it, and then we can do 3.0
 for the next release.

 Breaking the API again without a LTR in place makes me nervous as the 2.0
 API really wasn't that long ago.


+1 and even without officially breaking the API, plugin devs have been
quite busy with other changes which kept breaking plugins such as
multi-threaded rendering.


Best wishes,
Anita
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Matthias Kuhn]

Yes, 2.8 LTR is the least we need to do for users that spent time to
update to 2.0.

Matthias

On 08.11.2014 12:27, Anita Graser wrote:
 On Sat, Nov 8, 2014 at 8:01 AM, Nathan Woodrow madman...@gmail.com wrote:
 Personally I think we should still do 2.8, LTR it, and then we can do 3.0
 for the next release.

 Breaking the API again without a LTR in place makes me nervous as the 2.0
 API really wasn't that long ago.

 +1 and even without officially breaking the API, plugin devs have been
 quite busy with other changes which kept breaking plugins such as
 multi-threaded rendering.


 Best wishes,
 Anita
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Help getting QGIS to the next level of quality before November 15!
http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[G. Allegri]

+1 for LTS (2.6 or 2.8?).
A new API break risks to make users (and plugin developers) quite nervous!

E.G. the coming QEP from Nyall (about Composer refactoring) breaks Composer
gui API, while it should mantain core. This could be included in an LTS
release, while in QGIS 3.0 back compatibility can be discarded.

Just a question: typically an LTS brings backport updates during its
lifetime. In case of QGIS how would this happen? Will we provideca new
packaging for that release with a scheduling following the master release?

giovanni
Il 08/nov/2014 13:20 Matthias Kuhn matthias.k...@gmx.ch ha scritto:

 Yes, 2.8 LTR is the least we need to do for users that spent time to
 update to 2.0.

 Matthias

 On 08.11.2014 12:27, Anita Graser wrote:
  On Sat, Nov 8, 2014 at 8:01 AM, Nathan Woodrow madman...@gmail.com
 wrote:
  Personally I think we should still do 2.8, LTR it, and then we can do
 3.0
  for the next release.
 
  Breaking the API again without a LTR in place makes me nervous as the
 2.0
  API really wasn't that long ago.
 
  +1 and even without officially breaking the API, plugin devs have been
  quite busy with other changes which kept breaking plugins such as
  multi-threaded rendering.
 
 
  Best wishes,
  Anita
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer


 --
 Help getting QGIS to the next level of quality before November 15!
 http://blog.vitu.ch/10102014-1046/crowdfunding-initiative-automated-testing

 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Roy]

**If I may** +1 for LTS or LTR

Il 08/11/2014 15.09, G. Allegri ha scritto:


+1 for LTS (2.6 or 2.8?).
A new API break risks to make users (and plugin developers) quite nervous!



IMHO as an user myself i think that a working tool is more valuable than 
a new tool,


E.G. the coming QEP from Nyall (about Composer refactoring) breaks 
Composer gui API, while it should mantain core. This could be included 
in an LTS release, while in QGIS 3.0 back compatibility can be discarded.


Just a question: typically an LTS brings backport updates during its 
lifetime. In case of QGIS how would this happen? Will we provideca new 
packaging for that release with a scheduling following the master release?




always **if i can** and**IMHO** an LTS should be a tool that you know 
you can relay on
with known and expected behavior so no new feature only bugfix or 
critical bugfix


Best regards, and thanks for your great work,

Roy.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] QGIS 3.0?

[Nyall Dawson]

Hi all,

I'm just wondering - given a few large changes coming up, including:
- qt5 support, possibly breaking plugins
- potential composer redesign, breaking api
- geometry rework, where an api break would result in a better
foundation moving forward

... is it worth exploring the idea of making the next release QGIS 3.0
and breaking API? I know the original plan was for 3.0 to coincide
with python 3 support, but that doesn't appear to be anywhere on the
horizon yet.

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Nathan Woodrow]

Personally I think we should still do 2.8, LTR it, and then we can do 3.0
for the next release.

Breaking the API again without a LTR in place makes me nervous as the 2.0
API really wasn't that long ago.

- Nathan

On Sat Nov 08 2014 at 4:11:34 PM Nyall Dawson nyall.daw...@gmail.com
wrote:

 Hi all,

 I'm just wondering - given a few large changes coming up, including:
 - qt5 support, possibly breaking plugins
 - potential composer redesign, breaking api
 - geometry rework, where an api break would result in a better
 foundation moving forward

 ... is it worth exploring the idea of making the next release QGIS 3.0
 and breaking API? I know the original plan was for 3.0 to coincide
 with python 3 support, but that doesn't appear to be anywhere on the
 horizon yet.

 Nyall
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 3.0?

[Nyall Dawson]

On 08/11/2014 6:01 pm, Nathan Woodrow madman...@gmail.com wrote:

 Personally I think we should still do 2.8, LTR it, and then we can do 3.0
for the next release.

Couldn't we branch 2.6 off to become a LTR?

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer