General Assembly 2019

Australian QGIS user group has voted "Yes" to this item.

BTW I need document assiciated for each vote... in this round, I'm bit confised to asdsociacte the vote to the document I'm voting

Australian QGIS user group has voted "Yes" to this item.

Not clear the amount of reserve from the previous years... so I can0't evaluate if the 27K or more expenses are critical or not.

More money for bugfixing and general maintainance is good !

Australian QGIS user group has voted "Yes" to this item.

not clear to me what is the voice QGIS-IT 200 income

Australian QGIS user group has voted "Yes" to this item.

QGIS-US agrees

Australian QGIS user group has voted "Yes" to this item.

can't find reference to0 the discussion in loomio... sorry I'm late due to the conference and I need a clear entry point for previous discussion... and in this loomio I can't find reference

QGIS-US agrees

Australian QGIS user group has voted "Yes" to this item.

QGIS-US agrees

I don't to see how this will help, as users anyway start test after release, despite all our calls for testing.

I support this but I suspect it won't really help a lot as testing is just hard and because we can't force people to test it will still get left, but we can try it for a while with no harm really.

I've seen lots of release cycle discussions and lots of cycle changes and in fact nothing ever changed with testing, so I doubt something will change now. But if there is a need for change do it (and discuss the next release cycle change after the next release) ;)

I don't think this would improve the testing part but as it doesn't change anything for me and others think this will be an improvement, I agree.

I suggest that the difference between the latest QGIS version and the LTR should be communicated to the users more clearly. Currently I feel that if users stick to the LTR they feel like using something old - whereas the latest version might be more considered as a testing version. I assume some clarification on the types of releases might help in this issue a lot - also e.g. explain who might be the typical user for which release.

One of the original idea was also to lower pressure on developers by releasing less. To me the reformulated proposition makes it worse by shortening the dev window from about 13 weeks to 10.

What need to change is how testing is done before a release (especially LTR ones), regardless the how the release cycle is scheduled. This would make a substantial difference. In Coruña me and Alessandro made some example how this testing process could improved.

I would prefer to postpone this decision and create a working group that defines the goals (roles of LR vs. LTR and possible alternatives/accompanying measures) first. This proposal only addresses some of the points raised on the previous discussion on the original proposal. It's too late for 3.8, 3.10 is under a different LTR regime anyway, so there is no hurry. This decision can be made outside the AGM too.

This is not a bad idea, but I would have preferred the original proposal with fewer releases in order to reduce stress on developers. Also maybe RC releases to improve testing.

I don't think this will solve much. If the goal is to increase QA I believe that a real game changer would require (as we briefly discussed in Coruna) starting a group of volunteers for semi-automated and pre-release smoke tests and/or start creating a new set of CI application tests that run inside QGIS.

Australian QGIS user group has voted "Yes" to this item.

QGIS-US agrees

I think we should only have 2 releases pr year