[Qgis-developer] Release schedule discussion - again

Régis Haubourg regis.haubourg at eau-adour-garonne.fr
Mon Oct 12 07:49:08 PDT 2015

Thanks Andreas to raise the issue again. 

I feel stressed too with that release cycle as a public enterprise manager. 

Why ?

 - We try to push new features and fund them. It requires to test them when
they land in master and  restest them in all versions for regressions in

 - We have a delay between production deployment and LTR, depending on other
schedules than mine. so I currently have to support 2.6.1 in production,
test master during feature freeze, restest in 2.8, 2.10, in case I have to
switch back to LTR for next deployment.

 - If I keep to LTR, QGIS will loose early tester.. that's already the case. 
I can't follow three feature freeze periods in a year. Not sure not testing
only LTR versions helps QGIS project, since QGIS looses enterprise heavy use
cases here. The feature freeze and early patched version appears all the
time as Andreas said.

 - It is more pertinent and effective to test when developers are on the
work.. Six month later, tickets are kept in a pile. more overhead for

 - tickets are closed even before good testing, I need to reopen some often.
Risk of releasing a non tested patch.

 - Big features are introduced without QEP's written. Sorry for saying that,
I launch a funding for labeling rewrite and I see an API rewrite land in
Master, no blog, no doc, no QEP. The work is very good, but I can't rely on
such a roadmap with contracts relying on a blackbox project. This ends up in
more costs, because there is risk. We already have high costs with review,
quality, community work overhead.  

This ends to more overhead, which leads to fewer time to test. Unless... I
could hire someone. And this is impossible here. 

 More than all this, QGIS project is not able to review all the pending
PR's. I funded two features that won't make it in 2.12 because there wasn't
enought time for this. Postponing to 2.14 means rewriting a lot of code
because it won't be mergeable easily.  So.. I gain a lot of administrative
work on my side, and funded developpers gain a lot of risks on this. 

This is costy because we have to switch between to much versions at a time
and get lost in it. I also feel developpers being a bit too much "on the
edge" by now.

In my feeling, the 4 months release is more damageable than a 6 month
because of that "urge" feeling.

Please don't say user enterprise can jump over non LTR version, you know we
finance a lot, and if we don't stick to current project, we all loose

I think we must slow down, accept to postpone some new features, which is
hard to do and explain to funders. We need to all use QEP's, and that take
time to explain what is being done. 

I would love to be able to talk of all this with you in any developper
meeting, but budgets cuts just don't allow me to move from here. 


View this message in context: http://osgeo-org.1560.x6.nabble.com/Release-schedule-discussion-again-tp5229448p5229488.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.

More information about the Qgis-developer mailing list