Sun 24 Jan 2016 8:59PM

Vote to approve the process for QGIS 3.0

TS Tim Sutton Public Seen by 285

Recently I posted a blog post (http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/) summarising the considerations on how we should go about the process of putting out a QGIS 3.0 release. At the bottom of that posting is a proposal outlined by Matthias Kuhn. I created this thread so that we can agree or reject Matthias' proposal. In the situation where it is rejected, a viable alternative should be offered. Once we have an agreed upon roadmap, we should communicate this clearly to the greater QGIS user community.

For easy reference, here is Matthias' proposal:

QGIS 2.16 Release as usual in 4 months

-> PyQt5 Support
-> Python 3 Support
-> Wrapper library for PyQt4/PyQt5
-> Maybe a helper transition script that does 80% of the rewrite
-> All old plugins still work
-> Some python code is updated (console, plugin manager, processing) to
have some guidelines and experience how to update python code
-> For future debian, mac osx… versions there’s a qt5 version around
(with almost no plugins working)

During the same time: make some noise that QGIS 3 is coming and we need
everybody to put some money and dev time aside for it and that it’s
going to be amazing.

After that: 8 months break for 3.0 (maybe some betas after 4 months and
every month after)


Anita Graser Mon 25 Jan 2016 7:48AM

Thanks for keeping this rolling, Tim!


Paolo Cavallini Mon 25 Jan 2016 8:33AM

Agreed, thanks Tim!


Andreas Neumann Mon 25 Jan 2016 2:26PM

Looks good to me, Tim!


Poll Created Thu 28 Jan 2016 8:48AM

I approve the QGIS 3.0 development process as outline my Matthias Kuhn Closed Thu 4 Feb 2016 8:07AM


Results Option % of points Voters
Agree 50.0% 4 TS AN OD MH
Abstain 12.5% 1 GS
Disagree 37.5% 3 AG PC RD
Block 0.0% 0  
Undecided 0% 2 JEF JEF

8 of 10 people have voted (80%)


Tim Sutton
Thu 28 Jan 2016 8:49AM

It all looks good for me.


Richard Duivenvoorde
Thu 28 Jan 2016 3:57PM

I think we communicated enough we were going to make 2.14 the last and best (and LTR) 2.x version, and should now fully focus on a good 3.0


Paolo Cavallini
Thu 28 Jan 2016 6:48PM

More comments tomorrow.


Anita Graser
Fri 29 Jan 2016 12:04PM

agree with Richard's arguments


Jürgen E. Fischer Thu 28 Jan 2016 1:49PM

The proposal doesn't say who would be doing the work. We already agreed to work on this for 2.12, but not much was done.


Andreas Neumann Thu 28 Jan 2016 2:37PM

@jef - I think "who works on it" can be a separate decision. Once we decided on process and timing we will certainly ask our core devs if they can contribute and how much.


Andreas Neumann Thu 28 Jan 2016 2:38PM

We can spend some of our funds on the work for QGIS 3.0


Jürgen E. Fischer Thu 28 Jan 2016 2:54PM

Once we decided on process and timing we will certainly ask our core devs if they can contribute and how much.

Hm, and then revise the time frame to the available resources?


Tim Sutton Thu 28 Jan 2016 2:57PM

@jef One option is to keep putting out 4 monthly releases but labelled as beta until we are happy that 3.0 is "good enough". That we can can deal with delays in a way that still gives people early access to the 3.0 featureset without having to freeze the API till we are ready.


Jürgen E. Fischer Thu 28 Jan 2016 3:09PM

That's also odd. Why release something that we know is not good enough? If it's not good enough to release, we could skip releases all together, live with nightlies and start releasing again when 3.0 actually becomes good enough (maybe for 4-12 months).


Tim Sutton Fri 29 Jan 2016 6:36AM

@jef wrote:

That's also odd. Why release something that we know is not good enough? If it's not good enough to release, we could skip releases all together, live with nightlies and start releasing again when 3.0 actually becomes good enough (maybe for 4-12 months).

That sounds fine for me too....


Tim Sutton Fri 29 Jan 2016 6:41AM

@richardduivenvoord and @paolocavallini The proposal from Matthias does not promote 2.16 as the next LTR (as I read it anyway). It proposes:

  • Release 2.14 LTR
  • Release 2.16 as a 'migration release' that people can use as a basis for already getting their code Qt5, Python 3 and PyQt5 ready.
  • Release 3.0 and people who have been working on porting their code on 2.16 only need to focus on porting their code to cope with API breaking changes in QGIS 3.0

@andreasneumann proposal to treat 2.16 is a separate discussion (see https://www.loomio.org/d/QqnsRaGg/ltr-versions-should-be-supported-for-2-years)


Richard Duivenvoorde Fri 29 Jan 2016 8:01AM

Yes, that is clear to me.
It is just for the users that I want to end with a clear stable 2.x version.
And want to fully focus on getting ready for Qt5, Py3 & api 3.0
Telling our users that we are going to create another 2.x version (and maybe another one if that is 'needed'?) only leads to questions like Andreas' one: yes but can the last one then be a LTR (and if not now, we will hear it again when the migration to 3.0 takes a little longer then planned....).
We will need a bigger then 4 months window anyway to get a stable 3.0 anyway, so start with that asap. And do not promiss another 2.x version. IF users/companles want to stick to 2.x they can stick to 2.14 as a LTR as long as they want.
Give me one reason other then "we did not communicate" to have a 2.16. Because the communication point is (at least to me) not valid. Going to 2.16 only troubles our goals.
Maybe I sound a little black and white. But I think as a PSC we should stear as clear as possible. And I know communication is not our strongest point anyway, why would make 'communication' the most important argument now? Maybe we should spend more money on marketing instead of coding and docs >:P


Andreas Neumann Fri 29 Jan 2016 8:39AM

@richardduivenvoord The main reason why I want to have 2.16 is that in Switzerland there a lot of projects where organisations want to move to QGIS for editing Geodata. The forms support we have in QGIS is about 90% there - but there are several bits missing that we need to allow for a good user experience for a GIS operator.

This concerns mainly forms, relations, widgets, and transactions - I have detailed proposals if you are interested. There is also money around to address these issues within the next 3-4 months.

These projects are on province and municipality level and several of the organizations need solutions this year (2016) - they can't wait until 3.0 is maybe mature enough in 2017. We are at the mercy of the QGIS.ORG board. If you move directly to 3.0 - we are quite screwed. We would then have to probably move to the Sourcepole QGIS enterprise solution.

So there is a really concrete and urgent demand for another 2.x release.


Paolo Cavallini Fri 29 Jan 2016 10:33AM

I agree with @richardduivenvoord
My position:
* end up with 2.14 LTR
* start immediately with 3.0, and do all new stuff there
* in a few selected cases, if there are very good reasons, lift the feature freeze for LTR, and allow for extra functions to be backported, therefore avoiding the need for a 2.16


Andreas Neumann Fri 29 Jan 2016 12:32PM

hm - is this a funny game where people change their mind every day or two?


Andreas Neumann Fri 29 Jan 2016 12:33PM

sorry - for being a bit cynical. Not meant to be personal.


Andreas Neumann Fri 29 Jan 2016 12:43PM

We should also listen to our core devs - several of them (Matthias, Nyall, Nathan, Martin, Hugo) stated that they would like to have a 2.16 release.

See thread starting at http://lists.osgeo.org/pipermail/qgis-developer/2016-January/041014.html


Andreas Neumann Fri 29 Jan 2016 1:01PM

BTW: I don't have too strong feelings about 2.16 being an LTR - I am fine if 2.14 is an LTR like originally planned. But I would be in big, big troubles with my new employer, if code we order now won't be available until summer 2016.


Paolo Cavallini Fri 29 Jan 2016 1:03PM

Has the code a big impact? Which QEP?
If it's small, I think we can accommodate this and a few others as suggested above.


Andreas Neumann Fri 29 Jan 2016 1:16PM

The code hasn't been developed yet. The plan was to do it in the next release cycle. The new functionality we need is more about some smaller missing features and polishing.

I'll list a few here:
- Better support for n:m relations
- Improvements to the value relation widget
- Ability to define default values to fields/widgets
- Ability to define mandatory fields
- Better sorting in forms mode
- multi-column forms in the drag and drop mode
- Ability to save text values instead of numeric codes when exporting data (Save AS)
- Multiedit proposal at https://docs.google.com/document/d/1V9eKvarCQt9kUV3Z89BTyvMv3OzVSvwgFq433O_cJE4/edit
- Improved relation support in print composer
- aggregate functions on related tables

Things to make a edit session more efficient, streamlined and pleasant.


Anita Graser Fri 29 Jan 2016 1:26PM

If releasing a 2.16 has more advantages than disadvantages, then let's release it, but I'm against moving the LTR to 2.16.

  • 0 for 2.16 release -1 for 2.16 LTR

Jürgen E. Fischer Fri 29 Jan 2016 1:44PM

My preferred approach would still be:

  • Do a Qt5/PyQt5/Python3 branch in parallel, actually work on it until it's ready, make it master and release it as 3.0
  • Meantime keep working on master (2.x) and keep releasing them every 4 months as usual

Everyone can work on the branch (s)he wants (or is hired to), but needs to consider if (s)he want to do it (or spend funds on):

  • only for 2.x: knowing that it will be released soon; but might become unusable because platforms drop support for stuff it depends on sooner or later
  • only for 3,x: not knowing when that will ever release or
  • for both: knowing that work needs to be done twice.

As PSC we should maintain the environment for people to do something for QGIS - but we cannot tell them to - so we don't have resources we can actually plan with and that means we can either release something when the big thing is ready or what we have in fixed intervals.


Tim Sutton Mon 1 Feb 2016 9:47PM

@jef so you are basically promoting proposal #2 here :http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/ ? I think what I will do is make a few different proposals here on Loomio (proposal 1, proposal 2, Matthias' proposal) and we each vote yes or no on each of them. Please vote yes on only one and we can see which approach has the most votes. Sound ok for everyone? It would be nice to draw this discussion to a conclusion so we can move on with our lives and send a clear message to all the devs of what the plan is.


Andreas Neumann Wed 3 Feb 2016 4:46PM

Hi Tim,

I am ok with your proposal - it would be good to have this voting as soon as possible.

Our discussion is otherwise going in circles.

It might be useful to ask core devs about their opinion on this voting. If necessary, we could still separate PSC votes from core dev votes.

Is there a chance that we can have a decision by the end of next week at latest? Our sponsoring projects from QGIS-CH are sort of connected/affected by the decisions around QGIS 3.0


Tim Sutton Fri 5 Feb 2016 6:37PM

Just a concluding note that the PSC felt that the vote was split (1 non vote and 1 in favour was not enough of a majority) so we have discussed what to do about it in our meeting. We will post the outcome of that discussion shortly.