Hi
On Sun, Nov 4, 2012 at 1:15 PM, kimaidou kimai...@gmail.com wrote:
Hi all,
It would be great to tag the master branch whenever this comes out. This
way we will be able to compile the last master before the change.
I don't think there is much merrit in this (tagging) - API is already
On 11/02/2012 08:12 PM, Tim Sutton wrote:
I say this because I'm fairly sure there's a lot of us that use 1.9 as if it
were stable (or at least as stable as the development versions that turned into
1.7 and 1.8 were) and more than normally this is about not to be the case.
Yep /me guilty
On 11/03/2012 10:13 AM, Richard Duivenvoorde wrote:
On
11/02/2012 08:12 PM, Tim Sutton wrote:
I say this because I'm fairly sure
there's a lot of us that use 1.9 as if it were stable (or at
least as stable as the development versions
On Sat, Nov 3, 2012 at 10:01 AM, Micha Silver mi...@arava.co.il wrote:
On 11/03/2012 10:13 AM, Richard Duivenvoorde wrote:
And all qgis bloggers unite ;-) Let's all blog about this change...
That's an excellent suggestion. But it's not really clear (to me at least):
1- What's going to
On 27/10/2012, at 07:41 , Tim Sutton wrote:
Hi All
Firstly my apologies for taking so long to join in to this thread (and
for top posting) - I haven't been able to come up for air since
leaving Essen. In terms of the release roadmap for 2.0 the following
items were discussed in the
Hi
On Fri, Nov 2, 2012 at 12:25 PM, Ramon Andiñach cust...@westnet.com.au wrote:
On 27/10/2012, at 07:41 , Tim Sutton wrote:
Hi All
Firstly my apologies for taking so long to join in to this thread (and
for top posting) - I haven't been able to come up for air since
leaving Essen. In
Il 03/11/2012 04:12, Tim Sutton ha scritto:
How about we update the splash screen with a suitable 'this is going
to break some eggs' warning?
+1
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS:
Hi
On Sun, Oct 28, 2012 at 10:40 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Do you have a roadmap/timeline when you plan to merge the two steps? Tim: is
the feature freeze end of December?
Yes - I will post my detailed release checklist over the weekend.
Best regards
Tim
Hi Martin
Could you write an e-mail to the developer list once you have updated
the branch? It will be good to let people play a few days with the
branch before merging changes to trunk.
First I would like to merge API changes that are required in order to
get threaded rendering in place. I
On Sat, 2012-10-27 at 21:42 +0200, Martin Dobias wrote:
On Sat, Oct 27, 2012 at 2:46 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
Sounds like something worth considering.
Something else I have been thinking of and what would increase
performance pretty good in some situations would be to
2012/10/27 Paolo Cavallini cavall...@faunalia.it:
BTW, could please somebody move the important plugins still missing in
the new repo?
Where we can find this list of important plugins?
--
Alexander Bruy
___
Qgis-developer mailing list
On Sat, 2012-10-27 at 11:16 +0200, Sandro Santilli wrote:
On Sat, Oct 27, 2012 at 01:41:49AM +0200, Tim Sutton wrote:
* One of the major limitations I and the many people that contact me
about QGIS experience is lack of performance. Just yesterday I got an
email from someone in Sudan
On Thu, 2012-10-25 at 13:52 +0200, Martin Dobias wrote:
Yes, with the current design only one thread (iterator) can read
particular data at the same time.
Thank you for clarification.
In this case +1 from me for breaking the API.
Maybe most plugins can even be fixed with sed? And for others
Il 27/10/2012 16:57, Alexander Bruy ha scritto:
2012/10/27 Paolo Cavallini cavall...@faunalia.it:
BTW, could please somebody move the important plugins still missing in
the new repo?
Where we can find this list of important plugins?
good questions. I think for those on the new repo, the
Hi Martin
On Sat, Oct 27, 2012 at 12:08 PM, Martin Dobias wonder...@gmail.com wrote:
Hi Tim
On Sat, Oct 27, 2012 at 1:41 AM, Tim Sutton li...@linfiniti.com wrote:
In terms of the release roadmap for 2.0 the following
items were discussed in the hackfest in Essen as being the key
features we
Hi
On Sat, Oct 27, 2012 at 11:16 AM, Sandro Santilli s...@keybit.net wrote:
On Sat, Oct 27, 2012 at 01:41:49AM +0200, Tim Sutton wrote:
* One of the major limitations I and the many people that contact me
about QGIS experience is lack of performance. Just yesterday I got an
email from
On Sat, Oct 27, 2012 at 2:46 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
Sounds like something worth considering.
Something else I have been thinking of and what would increase
performance pretty good in some situations would be to be able to select
by an expression:
myFeatureSet =
On Sat, Oct 27, 2012 at 7:37 PM, Tim Sutton li...@linfiniti.com wrote:
while myProvider.nextFeature(myFeature): # or equivalent in new api
myGeometry = myFeature.geometry()
myFooValue = myFeature['foo']
do stuff .
Good news, that's on the branch already
Hi
On Sat, Oct 27, 2012 at 9:45 PM, Martin Dobias wonder...@gmail.com wrote:
On Sat, Oct 27, 2012 at 7:37 PM, Tim Sutton li...@linfiniti.com wrote:
while myProvider.nextFeature(myFeature): # or equivalent in new api
myGeometry = myFeature.geometry()
myFooValue =
Hi
On Sat, Oct 27, 2012 at 10:28 PM, Tim Sutton li...@linfiniti.com wrote:
Hi
On Sat, Oct 27, 2012 at 9:45 PM, Martin Dobias wonder...@gmail.com wrote:
On Sat, Oct 27, 2012 at 7:37 PM, Tim Sutton li...@linfiniti.com wrote:
while myProvider.nextFeature(myFeature): # or equivalent in new
On Sat, Oct 27, 2012 at 10:29 PM, Tim Sutton li...@linfiniti.com wrote:
By the way, what is the URI for your branch / repo - is it in a usable
state for others to play with?
Tim, my branch is available here [1], but I haven't updated it
recently because I have been modifying QgsFeature
Il 26/10/2012, Paolo Cavallini ha scritto:
For me it's not a problem if we release every 6 months. The most
important
thing is to release fixpacks (i.e. 1.7.1, 1.7.2, etc). For example, we
cannot use 1.8.0 because of bugs not present in 1.7.4 and it seems that
we
never see a 1.8.1
Hi All
Firstly my apologies for taking so long to join in to this thread (and
for top posting) - I haven't been able to come up for air since
leaving Essen. In terms of the release roadmap for 2.0 the following
items were discussed in the hackfest in Essen as being the key
features we would hold
Il 27/10/2012 08:41, Tim Sutton ha scritto:
For these reasons I vote +1 for Martin to merge in his work.
+1 for me too. I only think it is vital for the health of the project
that we make sure we do not release a 2.0 with hundreds of broken
plugins, in case plugin developers do not upgrade them
Hi,
This could be a solution. Release 1.9 this year (potentially a
Christmas present) with the new features we have now and then 2.0 in
summer or autumn 2013. We could do the feature freeze of 1.9 quite soon.
Andreas
On Thu, 25 Oct 2012 07:50:43 +0200, Marco Hugentobler wrote:
Hi
I
On Thu, Oct 25, 2012 at 12:48 AM, Paolo Cavallini cavall...@faunalia.it wrote:
I'm voting for a polished 2.0 release in a few month with the great feature
set we already have.
+1: let's release ASAP.
-1, of course let's release ASAP, but without creating future problems.
Please note that, as
On Thu, Oct 25, 2012 at 7:50 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Would it be an option to branch a 1.9 from current master just before Martin
merges the first breaking changes? That way, there would be a version with
all the nice 1.9 features and very little API breaks
Hi all,
I don't know if somebody already brought up this (the discussion is
already rather long), but is there no possibility for including legacy
methods?
For the iterators this would probably mean, that there is a reserved
iterator running single-threaded for any calls to the old API.
I don't
On Thu, Oct 25, 2012 at 09:21:46AM +0200, Radim Blazek wrote:
On Thu, Oct 25, 2012 at 7:50 AM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Would it be an option to branch a 1.9 from current master just before Martin
merges the first breaking changes? That way, there would be a
Il 25/10/2012 16:21, Radim Blazek ha scritto:
Very bad idea IMO. That would result exactly in what we don't want:
having multiple broken versions with different (not) working features
available in each one. Again the same problem with breaking API twice,
not enough resources to concentrate on
+1 for a spring or mid 2013 release of 2.0 with API break + plugin task
force. I was afraid that API change could lead to end 2013.
I would be please to support such an effort. I agree we need multithreading
enabled, and a polished API. But I remember the amount of effort needed to
release a
MORREALE Jean Roc wrote
The frequent feedback I get from institutions using QIGS is that they
want :
- bugfixes but no new functionalities
- but new useful functionalities (just for their specific use cases
of course)
- less frequent release to ease the software validation and their
On Thu, Oct 25, 2012 at 12:30 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
How does the new API handle this?
There is an iterator class that you would use like this:
QgsFeatureIterator it = layer.getFeatures(request)
while (it.nextFeature(f)) { do_something; }
The constructor typically
Hi devs,
My humble opinions :
* We should go for api breakage asap, or we will postpone it next time we
will speak again about it.
* +1 for contacting every plugin author and give them a documentation on
how to migrate their plugins to the new api.
* if plugin authors do not respond, we
Il 25/10/2012, qgis-developer-boun...@lists.osgeo.org ha scritto:
* we could release every 6 month like ubuntu, but I am not sure we have
the
manpower to do so. If yes, this will be the best IMHO
For me it's not a problem if we release every 6 months. The most important
thing is to release
2012/10/25 kimaidou kimai...@gmail.com:
Hum... reading my text above, it sounds too simple : I do not take into
account the need for bug fixing. One year without a bug fix can be very
long. And backporting means to have time and manpower... ARg, stuck again !
But now there are no backports
Il 25/10/2012 22:48, Luca Manganelli ha scritto:
For me it's not a problem if we release every 6 months. The most
important thing is to release fixpacks (i.e. 1.7.1, 1.7.2, etc). For
example, we cannot use 1.8.0 because of bugs not present in 1.7.4 and
it seems that we never see a 1.8.1
On Tue, Oct 23, 2012 at 10:58 PM, Pirmin Kalberer pi...@sourcepole.com wrote:
Hi Martin,
Am Montag, 22. Oktober 2012, 21.17:20 schrieb Martin Dobias:
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
2012/10/24 Radim Blazek radim.bla...@gmail.com:
Is there the 2.0 changes list written on flip chart on HF somewhere on
wiki? If not, I'll start one. Is there a photo?
As I can see from this photo [0] threading included to 2.0 roadmap but marked
as non-blocker
[0]
Hi!
Probably I missed something in Essen but to my knowledge it was always
clear that 2.0 will have _a lot of API Changes_ .. And I missed them
already. So now someone (Martin) is starting to bring us to a point
where a 2.0 really earns its big number change.
I am really looking forward to have
There is also something else to remember here. These changes that
Martin is proposing to merge are not the threading changes, it is the
API to allow threading to be added later. Even without threading
being added the API update is worth it. Having a cleaner API is
always a good thing.
Cleaner
On 23/10/2012 09:28, Sandro Santilli
wrote:
On Mon, Oct 22, 2012 at 09:35:05PM +0200, Werner Macho wrote:
Hi!
Short answer from me
+1 and go ahead .. As I remember we all knew that on the way to 2.0
there will be some API Changes - but as long as
Hi All,
As Martin asked, could we know more about 2.0 roadmap planning and feature
list?
My concern is that we deployed QGIS in prod for 300 users, but we still miss
some bugfixes and features to definitly switch. As long as I maintain two
GIS solutions, I have double work, and I can't dedicate
Hi Pirmin and others,
Tim should correct me - but as far as I remember we said that threading
support is one of the major things we want to see in QGIS 2.0 (along
with raster redesign, atlas printing and others). But none of us were
sure in what timeframe Martin can work on it and when it
Hi defs
Yes, the decision was that multithreading branch should be in 2.0.
Personally, I'm in favor of merging it as soon as possible (to give the
dev team enough time to get used to the new classes and to handle
possible side effects). Martin, is your planned merge already the full
Hi Martin, Andreas and others,
Am Mittwoch, 24. Oktober 2012, 16.13:34 schrieb Andreas Neumann:
Tim should correct me - but as far as I remember we said that threading
support is one of the major things we want to see in QGIS 2.0 (along
with raster redesign, atlas printing and others).
Hi Pirmin
On Wed, Oct 24, 2012 at 10:39 PM, Pirmin Kalberer pi...@sourcepole.com wrote:
We already have some API breaks. I've spent quite some time in Essen to get a
full list of it:
http://hub.qgis.org/wiki/quantum-gis/API_changes_for_version_20#Full-diff
My estimation is, that about 1% of
On Wed, Oct 24, 2012 at 10:38 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi defs
Yes, the decision was that multithreading branch should be in 2.0.
Personally, I'm in favor of merging it as soon as possible (to give the dev
team enough time to get used to the new classes and
Il 25/10/2012 05:39, Pirmin Kalberer ha scritto:
We did decide filling the missing gaps to fully replace old
symbology and old labelling (Paolo: Kickstarter pledge on the way?) and
polishing the many new features already integrated.
Sorry, no progress on this. I've asked for some feedback and
In the region I'm working in (Southeast Asia), QuantumGIS' adoption rate is
quickly rising, in big part due to fact that ArcGIS doesn't properly
support UTF-8.
Keeping these new adopters passionate about QGIS - as well as increasing
user base - with an healthy release cycle is IMO really
Date: Thu, 25 Oct 2012 07:48:30 +0900
From: Paolo Cavallini cavall...@faunalia.it
To: qgis-developer@lists.osgeo.org
Subject: Re: [Qgis-developer] Merging of incompatible changes
Message-ID: 5088703e.3070...@faunalia.it
Content-Type: text/plain; charset=ISO-8859-1
Il 25/10/2012 05:39
Hi
I understand Paolos and Pirmins concerns. Software like kde4 or gvsig
had or still have a long time of problems with major new versions. On
the other hand, I don't want to postpone the threading changes again and
again.
Would it be an option to branch a 1.9 from current master just before
Hi All,
a user point of view:
Go ahead, but advertise us! Thoses changes sound good.
+ 1 for Larry's proposal of separating Qsettings versions, since we all
spend some time running 1.8 AND master on the same machine and same user ...
Régis
--
View this message in context:
Hi,
For me it is ok to go ahead and break the API. That was our goal for
version 2.0.
But perhaps we can especially mark the version before those big changes
in github and create a parallel version in OSGeo4W that still works. I
don't ask to work on two versions in parallel, just to keep a
On Mon, Oct 22, 2012 at 09:35:05PM +0200, Werner Macho wrote:
Hi!
Short answer from me
+1 and go ahead .. As I remember we all knew that on the way to 2.0
there will be some API Changes - but as long as it improves QGIS at a
Project I see no Problem for it ..
The only thing you are
Hi all,
I second Andreas with the idea of a frozen master version which is very
usable for end-users who need the last improvements.
Greetings,
Denis
On 10/23/2012 09:23 AM, Andreas Neumann wrote:
Hi,
For me it is ok to go ahead and break the API. That was our goal for
version 2.0.
On Tue, Oct 23, 2012 at 9:12 AM, haubourg
regis.haubo...@eau-adour-garonne.fr wrote:
Hi All, a user point of view:
Go ahead, but advertise us! Thoses changes sound good.
+ 1 for Larry's proposal of separating Qsettings versions, since we all
spend some time running 1.8 AND master on the same
Hi,
On Mon, Oct 22, 2012 at 8:17 PM, Martin Dobias wonder...@gmail.com wrote:
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
developers. I would like to merge the changes soon to master branch in
order
Il 23/10/2012 16:23, Andreas Neumann ha scritto:
Hi,
For me it is ok to go ahead and break the API. That was our goal for
version 2.0.
I generally agree, I'm just worried about missing too many plugins along
the road, not being upgraded. To prevent this, IMHO we should:
- centralize all
Hi Martin
In your changes, are there also other api-breaking things besides the
Python changes ( related to 1) enable introduction of threading )?
Regards,
Marco
On 22.10.2012 21:17, Martin Dobias wrote:
Hi all
recently I have been brewing some backwards incompatible API changes
that will
2012/10/23, Denis Rouzaud denis.rouz...@gmail.com:
I second Andreas with the idea of a frozen master version which is very
usable for end-users who need the last improvements.
I second Andreas too.
I'm currently finishing a project using 1.9-master because some
bugfixes like the ones for bug
On Tue, Oct 23, 2012 at 3:58 PM, Marco Hugentobler
marco.hugentob...@sourcepole.ch wrote:
Hi Martin
In your changes, are there also other api-breaking things besides the Python
changes ( related to 1) enable introduction of threading )?
Hi Marco
yes there are (will be) also other changes,
On Tue, Oct 23, 2012 at 10:03 AM, Radim Blazek radim.bla...@gmail.com wrote:
On Tue, Oct 23, 2012 at 9:12 AM, haubourg
regis.haubo...@eau-adour-garonne.fr wrote:
Hi All, a user point of view:
Go ahead, but advertise us! Thoses changes sound good.
+ 1 for Larry's proposal of separating
On Tue, Oct 23, 2012 at 9:28 AM, Sandro Santilli s...@keybit.net wrote:
And once all those changes settled in (upcoming) 2.0 - from my point of
view it would be time for a new release ..
Probably we should introduce a max.Version to plugins too? ;)
I think all changes should be made backward
Hi Martin,
Am Montag, 22. Oktober 2012, 21.17:20 schrieb Martin Dobias:
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
developers. I would like to merge the changes soon to master branch in
order not to
Hi Pirmin
On Tue, Oct 23, 2012 at 10:58 PM, Pirmin Kalberer pi...@sourcepole.com wrote:
Hi Martin,
Am Montag, 22. Oktober 2012, 21.17:20 schrieb Martin Dobias:
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API
On Wed, Oct 24, 2012 at 7:52 AM, Martin Dobias wonder...@gmail.com wrote:
But who will maintain that branch? I do not have enough free time to
keep a separate branch up-to-date with master for a long period (until
3.0)
Also given that we do a release around every six month, or so, it will
be a
Il 24/10/2012 06:56, Nathan Woodrow ha scritto:
Also given that we do a release around every six month, or so, it will
be a long while before we ever see a 3.0. The API is already broken I
think we should get it all done with now and move on. Once we release
2.0 we are locked to that API for a
On 10/23/2012 11:35 PM, Martin Dobias wrote:
On Tue, Oct 23, 2012 at 9:28 AM, Sandro Santilli s...@keybit.net wrote:
And once all those changes settled in (upcoming) 2.0 - from my point of
view it would be time for a new release ..
Probably we should introduce a max.Version to plugins too? ;)
Hi all
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
developers. I would like to merge the changes soon to master branch in
order not to drift too much from master.
The changes will break lots of plugins,
Hi!
Short answer from me
+1 and go ahead .. As I remember we all knew that on the way to 2.0
there will be some API Changes - but as long as it improves QGIS at a
Project I see no Problem for it ..
The only thing you are worrying about are the Plugins .. but hey - there
is still 1.8 ..
And once
Hi!
Short answer from me
+1 and go ahead .. As I remember we all knew that on the way to 2.0
there will be some API Changes - but as long as it improves QGIS at a
Project I see no Problem for it ..
The only thing you are worrying about are the Plugins .. but hey - there
is still 1.8 ..
And once
Hi Martin,
2012/10/22 Martin Dobias wonder...@gmail.com:
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
developers. I would like to merge the changes soon to master branch in
order not to drift too much
Hi Martin,
On Mon, Oct 22, 2012 at 1:17 PM, Martin Dobias wonder...@gmail.com wrote:
Hi all
recently I have been brewing some backwards incompatible API changes
that will 1) enable introduction of threading, 2) simplify API for
developers. I would like to merge the changes soon to master
Il 22/10/2012 21:35, Werner Macho ha scritto:
Probably we should introduce a max.Version to plugins too? ;)
agreed, this should solve most of the headaches.
I think we should advertise the breaking of the ddev version widely, as
many users (we spoiled them) have become accustomed to it, even in
75 matches
Mail list logo
