Vote to approve the process for QGIS 3.0

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

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

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.

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.

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.

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

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.

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

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

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.