gistfile1.txt

--- Log opened Mo Feb 20 00:00:25 2017
09:59 < timlinux> hi all
10:00 < nyalldawson> hey
10:00 < timlinux> hi
10:01 < nyalldawson> are we moving here?
10:01 < timlinux> @pcav and @jef-n did you see the request from Nyall to move here?
10:01 < gitter> [Github] elpaso commented in qgis/QGIS on issue: [feature] QgsSettings QGIS QSettings replacement https://github.com/qgis/QGIS/pull/4160#issuecomment-281022603
10:01 < timlinux> or I can make a side channel
10:01 < jef-n> no.
10:01 < nyalldawson> sorry my daughter is going crazy so i can't do voice
10:01 < nyalldawson> need her to sleep :P
10:02 < timlinux> @timlinux does not mind where we chat
10:02 < timlinux> ok we just need @pcav ....
10:03 < m-kuhn> hi
10:03 < timlinux> -----
10:03 < timlinux> # QGIS Release Roadmap Meeting 
10:03 < timlinux> -----
10:04 < timlinux> # Present
10:04 < timlinux> 
10:04 < timlinux> * @timlinux
10:04 < timlinux> * @nyalldawson 
10:04 < timlinux> * @jef-n 
10:04 < timlinux> * @m-kuhn 
10:04 < timlinux> * @pcav 
10:04 < timlinux> 
10:04 < timlinux> 
10:04 < NathanW2> Can I hang out here too?
10:04 < gitter> [Github] 3nids commented in qgis/QGIS on issue: [feature] QgsSettings QGIS QSettings replacement https://github.com/qgis/QGIS/pull/4160#issuecomment-281023307
10:04 < m-kuhn> Please do!
10:04 < timlinux> * anyone else interested (please let @pcav lead the agenda so we dont get lost in side conversations though)
10:04 < nyalldawson> @NathanW2 no :P
10:05 < NathanW2> @nyalldawson I'll see myself out ;P
10:05 < timlinux> [edit] # Present
10:05 < timlinux> [edit] 
10:05 < timlinux> [edit] * @timlinux
10:05 < timlinux> [edit] * @nyalldawson 
10:05 < timlinux> [edit] * @jef-n 
10:05 < timlinux> [edit] * @m-kuhn 
10:05 < timlinux> [edit] * @pcav 
10:05 < timlinux> [edit] * @NathanW2
10:05 < timlinux> [edit] 
10:05 < nyalldawson> actually i feel guilty cos I forgot to ask you
10:05 < NathanW2> meh
10:05 < NathanW2> not stressed, you all continue I will just pop in and out as I'm doing stuff
10:06 < m-kuhn> I'll have to leave around 10:30
10:06 < timlinux> @NathanW2 you are more than welcome
10:06 < gitter> [Github] m-kuhn commented on a commit in qgis/QGIS https://github.com/qgis/QGIS/commit/382b213ed19cac8356662de6e75d79a9b2fed2ab#commitcomment-20955254
10:07 < nyalldawson> Is Paolo here?
10:07 < timlinux> While we wait for Paolo I guess I can say that his agenda is to try to come up with a communications strategy (good corporate wording eh?) for the 3.0 release
10:07 < jef-n> on irc.
10:07 < timlinux> @nyalldawson I don't know where he has got to
10:08 < gitter> [Github] m-kuhn commented in qgis/QGIS on issue: [feature] QgsSettings QGIS QSettings replacement https://github.com/qgis/QGIS/pull/4160#issuecomment-281024023
10:08 < timlinux> @jef-n http://gitter.im/qgis/QGIS <-- he can join here
10:08 < timlinux> in his web browser
10:08 < gitter> [Github] NathanW2 commented in qgis/QGIS on issue: [feature] QgsSettings QGIS QSettings replacement https://github.com/qgis/QGIS/pull/4160#issuecomment-281024210
10:09 < gitter> [Github] nyalldawson commented on a commit in qgis/QGIS https://github.com/qgis/QGIS/commit/382b213ed19cac8356662de6e75d79a9b2fed2ab#commitcomment-20955287
10:09 < gitter> [Github] NathanW2 commented in qgis/QGIS on issue: [feature] QgsSettings QGIS QSettings replacement https://github.com/qgis/QGIS/pull/4160#issuecomment-281024210
10:10 < gitter> [Github] 3nids pushed 2 commit(s) to qgis/QGIS https://github.com/qgis/QGIS/compare/741e11df9703...e53ad479392f
10:11 < timlinux> @pcav are you here?
10:11 < NathanW2> @timlinux I have it: "QGIS is the best GIS. People tell me it's the best. We make the best GIS system ever. Smartest people"
10:11 < NathanW2> :P
10:11 < timlinux> hehe
10:11 < NathanW2> "Make GIS Great Again"
10:12 < gitter> [Github] m-kuhn commented on a commit in qgis/QGIS https://github.com/qgis/QGIS/commit/382b213ed19cac8356662de6e75d79a9b2fed2ab#commitcomment-20955312
10:12 < pcav> Hi Tim, all
10:12 < pcav> here I am
10:12 < timlinux> I think he has more in mind:
10:12 < timlinux> * what minimim set of features should be considered blockers for the release
10:12 < timlinux> * what the release timing will be
10:12 < timlinux> 
10:12 < nyalldawson> Hey Paolo
10:12 < timlinux> hi!
10:12 < pcav> should we keep on here?
10:12 < timlinux> Yes sure
10:13 < nyalldawson> i don't think it's anything confidential, right?
10:13 < timlinux> nope
10:13 < pcav> not at all
10:13 < pcav> Ok, then
10:13 < timlinux> @pcav please dive in and layout the main discussion points
10:14 < pcav> Perhaps I should start asking what is the current state, if you see any stumbling blocks
10:14 < pcav> the objective of the meeting is to outline our strategy for QGIS 3 release
10:14 < pcav> if possible, with an idea about timing
10:15 < pcav> that's it
10:16 < pcav> Nyall, do you want to tell us?
10:16 < nyalldawson> the current state? seems good to me ... nice and stable, i don't think there's many regressions
10:16 < pcav> agreed, almost usable
10:17 < jef-n> almost?
10:17 < gitter> [Github] nyalldawson commented on a commit in qgis/QGIS https://github.com/qgis/QGIS/commit/382b213ed19cac8356662de6e75d79a9b2fed2ab#commitcomment-20955353
10:17 < timlinux> Can you guys make a brain dump of what you consider to be criteria for releasing 3.0 (in terms of API changes still in the wings and new features)?
10:17 < pcav> I mean, do you think there is still a lot of work to be completed before freeze?
10:17 < nyalldawson> Well, there's still some quite large refactoring work going on
10:17 < nyalldawson> Martin's project stuff for instance
10:18 < timlinux> @timlinux would like to see the new metadata system we are about to propose added
10:18 < nyalldawson> I've got some canvas and tool stuff coming down for multi-canvas
10:18 < NathanW2> I guess the main question I have is.  What's the rush to freeze it?
10:18 < nyalldawson> Hoping to do composer rewrite still, also lots of processing changes inbound (port to c++)
10:19 < timlinux> @NathanW2 I'm not sure there is a rush - just a desire to let people know what is going on so they can plan their work
10:19 < NathanW2> @timlinux ok no worries. 
10:19 < nyalldawson> my opinion... the work is going fantastic. The changes done so far are all fantastic and should really make qgis 3 much more stable and performant, with a much nicer scripting api
10:19 < nyalldawson> i don't want to stop :P
10:19 < timlinux> hehe
10:19 < nyalldawson> (but can acknowledge that indefinite future release is a bad thing too)
10:20 < NathanW2> what is the ETA on the stuff you listed @nyalldawson?
10:20 < nyalldawson> also i should add i think there's still lots of server stuff inbound too
10:21 < nyalldawson> i think mid-year is a good aim
10:21 < nyalldawson> for release
10:21 < m-kuhn> I am very happy with the current state, there are a lot of very nice improvements present and the overall stability is quite good (maybe already now even better than any 2.x release [citation needed] )
10:21 < nyalldawson> cite me there :P
10:21 < nyalldawson> i strongly believe that
10:21 < haubourg> Hi guys, yes server refactoring is on and we have that freee in june, release in july in mind 
10:21 < haubourg> [edit] Hi guys, yes server refactoring is on and we have that freze in june, release in july in mind 
10:21 < timlinux> Hey @haubourg 
10:21 < haubourg> [edit] Hi guys, yes server refactoring is on and we have that freeze in june, release in july in mind 
10:22 < m-kuhn> I must admit that I lost a bit track of all the refactoring due to other projects which have kept me busy
10:22 < timlinux> What about moving 2.18 to be LTR and telling folks to expect the 3.x based LTR only in Q1 2018?
10:23 < nyalldawson> i like the idea of a final 2.x ltr
10:23 < NathanW2> same
10:23 < NathanW2> bias because of style dock :P
10:23 < haubourg> Same, very much asked by users
10:23 < timlinux> that gives plenty of time to get the remaining features in , add lots of polish, have fresh stuff for the 2.x LTR users
10:23 < NathanW2> but 2.14 feels old now
10:23 < timlinux> seems like a win win all around
10:23 < nyalldawson> i know a lot of enterprise have moved to 2.18 because they needed the new features
10:23 < haubourg> +12
10:23 < m-kuhn> LTR requires to feel old
10:23 < timlinux> I use 2.14 every day - its a great release :-)
10:23 < m-kuhn> [edit] LTR needs to feel old
10:24 < haubourg> whent 2.18 is LTR, QGIS3 will make it feel old :)
10:24 < m-kuhn> I think our promise was to keep 2.14 alive until June (?)
10:24 < nyalldawson> could we go 2.14->june then 2.18?
10:24 < jef-n> it already is.  there are point releases for 2.14 and 2.18
10:24 < jef-n> until there is 3.x
10:25 < nyalldawson> i guess it's more a question of after 3.0
10:25 < m-kuhn> I guess the question then is if we want to retire 2.14 in June
10:25 < nyalldawson> would we stop the 2.18.x releases or not?
10:25 < NathanW2> @jef-n I have noticed that, I think it's more related to the messaging around it
10:25 < m-kuhn> And until when we promise to patch 2.18
10:26 < pcav> IMHO the main point against postponing much later than the summer is that new important features need to be backported
10:26 < m-kuhn> -1 on backporting
10:26 < m-kuhn> that's not the reason for LTR
10:26 < pcav> at it happened eg for DWG, and this creates a sort of a hybrid situation
10:26 < jef-n> yes, -1.
10:26 < timlinux> @m-kuhn I think @pcav more means that people adding new features dont have a way to see them in the LTR for another year
10:26 < pcav> sure, we all agree LTR should havew bugfix only
10:27 < pcav> but the reality is that we have more and more pressure to add important stuff
10:27 < pcav> @timlinux exactly, thanks for explaining
10:27 < gitter> [Github] elpaso synchronize a Pull Request to qgis/QGIS: [feature] QgsSettings QGIS QSettings replacement https://github.com/qgis/QGIS/pull/4160
10:27 < m-kuhn> I'd say that important stuff with time pressure and LTR are orthogonal concepts
10:27 < timlinux> I think we can resist the pressure
10:28 < timlinux> If people *must* use the new features, let them use the nightlies
10:28 < m-kuhn> If people ask for new stuff, thell them to upgrade
10:28 < m-kuhn> [edit] If people ask for new stuff, tell them to upgrade
10:28 < pcav> this is not what we are doing
10:28 < pcav> we did integrate DWG
10:28 < m-kuhn> ... or write a plugin ...
10:28 < pcav> and this was a good move IMHO
10:28 < m-kuhn> DWG was an exception on a non LTR release
10:28 < jef-n> because we didn't want a 2.20
10:29 < pcav> table speedup by Nyall of today is also stuff that can't really wait IMHO
10:29 < nyalldawson> what features are we talking about? hypothetical ones? or is there actual examples?
10:29 < m-kuhn> special circumstances, I never thought this way of doing things will become standard
10:29 < nyalldawson> oh that's a bugfix
10:29 < nyalldawson> 100% bugfix
10:29 < pcav> OK, so mcuh better
10:29 < jef-n> BTW gpkg was also improved
10:30 < nyalldawson> something to keep in mind is that it'd be a HUGE job to backport features from 3.0 -> 2.18 now
10:30 < m-kuhn> Questions:
10:30 < m-kuhn> 
10:30 < m-kuhn>  * retire 2.14 in june (?)
10:30 < m-kuhn>  * what's the EOL for 2.18 (if it becomes LT) 
10:30 < timlinux> * Y
10:30 < nyalldawson> so not sure anyone really wants to do that
10:30 < timlinux> * March 2018
10:30 < m-kuhn> @m-kuhn is slowly getting ready to leave
10:30 < pcav> OK, so is there a general consensus "wait until ready, no date" and "2.18 LTR, no new features, allowing special exceptions"?
10:31 < nyalldawson> +1
10:31 < m-kuhn> I would like to have a date
10:31 < nyalldawson> but tentative date of mid year
10:31 < timlinux> @pcav I dont see why we cant set a date
10:31 < m-kuhn> [edit] I would prefer to have a date
10:31 < m-kuhn> tentative is fine as well
10:31 < pcav> most people outside here would like it
10:31 < timlinux> but just that we should not make it soon
10:31 < timlinux> **too** soon
10:32 < NathanW2> @NathanW2 should have his contacts in because he say March and freaked out :P
10:32 < NathanW2> [edit] @NathanW2 should have his contacts in because he saw March and freaked out :P
10:32 < timlinux> March **2018**
10:32 < NathanW2> :)
10:32 < timlinux> [edit] # March **2018**
10:33 < timlinux> No need for glasses now :-)
10:33 < NathanW2> @timlinux that's a bit better 
10:33 < NathanW2> I would be cool with that, because I haven't had time to do anything yet so longer the better for me
10:33 < m-kuhn> Proposal
10:33 < m-kuhn> 
10:33 < m-kuhn>  * retire 2.14 as planned
10:33 < m-kuhn>  * patch 2.18 until January 2018
10:33 < m-kuhn>  * release 3.2 as next LTR in January 2018
10:33 < m-kuhn>  * feature freeze (3.0) in May
10:33 < m-kuhn>  * release 3.0 in July
10:33 < pcav> so, tentatively 2018/3 for release, freeze 2 months before?
10:34 < m-kuhn> [edit] Proposal
10:34 < m-kuhn> [edit] 
10:34 < m-kuhn> [edit]  * retire 2.14 as planned
10:34 < m-kuhn> [edit]  * patch 2.18 until January 2018
10:34 < m-kuhn> [edit]  * release 3.2 as next LTR in January 2018
10:34 < m-kuhn> [edit]  * feature freeze (3.0) in May 2017
10:34 < m-kuhn> [edit]  * release 3.0 in July 2017
10:34 < pcav> oh, sorry @m-kuhn 
10:34 < timlinux> So since we are all running out of time how about we do this:
10:34 < timlinux> 
10:34 < timlinux> * Tim draft a blog article with the above (as per @m-kuhn 's list)
10:34 < timlinux> * Circulate text to you all for agreement
10:34 < timlinux> * Post on blog
10:35 < pcav> @m-kuhn thata means no API break after May 2017?
10:35 < m-kuhn> correct
10:35 < pcav> @nyalldawson how does it sound? too early?
10:35 < nyalldawson> i'd loosen that a little... freeze in may, but still allow breaks during bug fixing
10:35 < m-kuhn> proposal only, there are quite a few people who can put a veto there ;)
10:35 < pcav> ;)
10:36 < gitter> [Github] 3nids synchronize a Pull Request to qgis/QGIS: Allow to use API without QgsApplication instance https://github.com/qgis/QGIS/pull/4113
10:36 < m-kuhn> I'll leave the decision with you as I've got to leave now
10:36 < m-kuhn> will read your decision later
10:36 < m-kuhn> have fun
10:36 < nyalldawson> ok.... I volunteer @m-kuhn to do everything :)
10:36 < NathanW2> I would prefer to see a little extra padding but that is just me
10:36 < timlinux> cya @m-kuhn 
10:36 < nyalldawson> +1 to @NathanW2 
10:36 < nyalldawson> but i could live with it
10:36 < nyalldawson> i really need to launch the composer fundraising as that's the only thing in my mind
10:36 < timlinux> What would the padded timeline look like?
10:37 < nyalldawson> but that's always doable outside of freeze
10:37 < NathanW2> +2 months on ecah
10:37 < nyalldawson> +2 months
10:37 < NathanW2> [edit] +2 months on each
10:37 < pcav> OK, so freeze in July?
10:37 < NathanW2> yeah
10:37 < pcav> we can always raise it for special reasons
10:38 < nyalldawson> that sits better with me
10:38 < timlinux> So:
10:38 < timlinux> 
10:38 < timlinux> Proposal
10:38 < timlinux> 
10:38 < timlinux>  * retire 2.14 as planned
10:38 < timlinux>  * patch 2.18 until March 2018
10:38 < timlinux>  * release 3.2 as next LTR in March 2018
10:38 < timlinux>  * feature freeze (3.0) in July 2017
10:38 < timlinux>  * release 3.0 in Sept 2017
10:38 < pcav> allowing the break of a couple of methods shouldn't be so bad afer all
10:38 < nyalldawson> i like it
10:38 < timlinux> @jef-n how does the above sound for you?
10:38 < NathanW2> Yes please
10:38 < nyalldawson> *but acknowledge that i have a very developer-heavy viewpoint
10:39 < pcav> @timlinux seems fine to me, but of course @nyalldawson @jef-n and others have the final word
10:39 < NathanW2> @nyalldawson do you know the ETA on Martins stuff?
10:39 < jef-n> @timlinux good - except declaring an existing release as ltr is unexpected
10:39 < timlinux> I think the main idea of @pcav is just that we have something to tell people so they can plan their work programmes 
10:39 < m-kuhn> Updated Proposal
10:39 < m-kuhn> 
10:39 < m-kuhn>  * retire 2.14 as planned
10:39 < m-kuhn>  * patch 2.18 until March 2018
10:39 < m-kuhn>  * release 3.2 as next LTR in release 3.0 + 4 Months
10:39 < m-kuhn>  * feature freeze (3.0) in July 2017
10:39 < m-kuhn>  * release 3.0 in Sept 2017
10:39 < nyalldawson> Nope... i think it's a continual wip
10:40 < NathanW2> @jef-n I guess here it might be ok given the long time between 2.14 and 3.0 release
10:41 < NathanW2> so if we make 2.18 that gives people heaps of new stuff to sit on while 3.0 is under test
10:41 < timlinux> @jef-n RE existing release -> LTR : any other suggestions? Stick with 2.14 LTR until 3.2 LTR?
10:41 < timlinux> I think we will make lots of people happy if we do 2.18 -> 2.18 LTR
10:42 < pcav> except possibly people using qgis-server
10:42 < nyalldawson> why is that @pcav ?
10:42 < timlinux> @pcav why ?
10:42 < timlinux> They can still deploy 2.14 if they need it
10:43 < jef-n> @timlinux I don't see a problem with continuing with the two and master.   but I'm not vetoing dropping 2.14.
10:43 < timlinux> I am -0 on dropping 2.14
10:44 < jef-n> -0 sounds right ;)
10:44 < timlinux> but are you suggesting a world where we have 2.14LTR + 2.18 LTR?
10:44 < jef-n> that's what we effectively have
10:44 < nyalldawson> not really... we haven't made any promises about lifetime of 2.18
10:44 < timlinux> yes other than the three letters behind the name of 2.18 we do
10:45 < timlinux> so when would we kill off 2.14? March 2018?
10:46 < timlinux> and then EOL for 2.18 in March 2019? 
10:46 < timlinux> Then we effectively have a 2 year maintenance period for LTR's
10:46 < jef-n> on every major release ;)
10:46 < timlinux> which would be really nice because IMHO 1year is too short
10:46 < pcav> @timlinux 
10:46 < pcav> agreed
10:47 < timlinux> @pcav how about you bounce the summary around the dev list first
10:47 < nyalldawson> was there anything else we needed to decide?
10:47 < jef-n> so more releases?   2x ltr + 1 regular
10:48 < pcav> -1 for 2 LTR
10:48 < timlinux> and then if there are no major dessentors, I will post a blog article for our broader user bases
10:48 < timlinux> um
10:48 < timlinux> I thought it would work more like:
10:48 < jef-n> so a ltr every two years?
10:49 < jef-n> ltr will feel really old
10:49 < timlinux> yeah I guess
10:49 < nyalldawson> yeah
10:49 < timlinux> and two concurrent LTR's will be a bit of a headache
10:49 < nyalldawson> what's 2 years old now? 2.10? 2.06?
10:50 < nyalldawson> 2.8. ancient
10:51 < haubourg> I agree two years is very loong for QGIS dynamic. But some users start to build  by  apps that will probably last for 5 or 6 years.. 
10:51 < haubourg> I guess they can find some support if needed anyway
10:52 < timlinux> ok so we have this alternative:
10:52 < timlinux> Updated Proposal
10:52 < timlinux> 
10:52 < timlinux>  * retire 2.14 as planned in June 2017
10:52 < timlinux>  * patch 2.18 becomes LTR from June 2017 to  2018
10:52 < timlinux>  * release 3.2 as next LTR in release 3.0 + 4 Months (eta June 2018)
10:52 < timlinux>  * feature freeze (3.0) in July 2017
10:52 < timlinux>  * release 3.0 in Sept 2017
10:52 < timlinux> @jef-n does that fit better to how you would do things?
10:52 < timlinux> (aside from the '2.18LTR is a surprise' part)
10:53 < nyalldawson> (i've got maybe 5-10 mins left)
10:53 < jef-n> so 2.18 will replace 2.14 as ltr and 3.2 will replace 2.18
10:54 < jef-n> so we'll keep ltrs for 1y
10:54 < timlinux> yes
10:54 < timlinux> yes
10:54 < jef-n> fine
10:54 < pcav> OK, so
10:54 < pcav> decided?
10:54 < timlinux> and we wait till we get a gazillion dollars in funding so we can pay maintainers to extend our LTR's out to 2 years
10:55 < timlinux> :+1:  from me for last list above
10:55 < NathanW2> +1
10:55 < NathanW2> :cake: 
11:01 < pcav> fine
11:01 < pcav> @timlinux so I'm sending a quick mail to qgis-dev, OK?
11:04 < timlinux> perfect
11:04 < timlinux> then once the discussion is concluded (maybe set a time cap?) I will post to the blog
11:09 < pcav> very well, thank you all
11:09 < nyalldawson> thanks all!
11:10 < timlinux> thanks all! Thanks @pcav 
11:18 < pcav> done
11:18 < NathanW2> thanks