[Qgis-psc] A plea for backporting

[Tim Sutton]

Hi Markus

On Fri, Feb 11, 2011 at 11:59 PM, Markus Neteler <neteler at osgeo.org> wrote:
> Fellow PSC members,
>
> as a long term QGIS user and an even longer FOSS4G activist I would like
> to bring the following wish to your kind attention: please backport bugfixes.
>
> Unlike other FOSS projects (GDAL, GRASS, ...) the QGIS project does not
> offer backports of even important bugfixes to the last stable release
> branch(es).
>
> Looking at the changelog at http://trac.osgeo.org/qgis/browser/branches :
>
> Branch    rev   age     Last Change
>  Release-1_3_0  11661   17 months       macho: translation update: uk by sergey
>  Release-1_4_0  12730   13 months       timlinux: Removed duplicate entry in
> index.html and regenerated application default …
>  Release-1_5_0  14255   5 months        macho: correct some typos in fr by jean roc
>  Release-1_6_0 14615    3 months        kyngchaos: fix release name
>
> ... we observe that branches get essentially abandoned once a release is done.
> Looking at http://www.qgis.org/wiki/Release_Roadmap I understand that QGIS 1.4
> should be updated. But the last change was done more than one year ago.
>
> Comparing that to GDAL:
> Branch    rev   age     Last Change
>  1.6    21472   4 weeks         warmerdam: Fixed order of arguments to VSIRename.
>  1.7    21609   12 days         rouault: NITF: correctly assign hemisphere for a
> ICORDS='U' NITF file with …
>
> or GRASS:
> Branch    rev   age     Last Change
>  releasebranch_6_3      45008   4 weeks         neteler: formula correction
>  releasebranch_6_4      45380   22 minutes      msieczka: Set svn:mime-type to
> 'text/x-plain; charset=utf-8 to fix UTF-8 rendering …
>
> we see that here even the last but one stable release branch received bugfixes.
>
> So, why are backports of (important) bugfixes needed?
>
> While I support the "release-often" paradigm, this does not exclude
> backports to be
> done. Sure, it is a pain for the developers but it is an excellent
> service for long term
> users. Example: I am running these three software packages on several machines,
> some of them are used by many users. Naturally I don't want to break things and
> risk that they flood me with questions "why is all different" [as it
> may happen in
> a new release]. Moreover I prefer to merge in bugfixes and that's it.
> Easily done
> for GRASS and GDAL. Maybe once a year I update to the next stable release.
> This concept works well for me for many years.
>
> Imagine the IT folks of a public administration. For sure they will
> not change the
> installation every 6 month. But exchanging a DLL or whatever file, maybe yes.
> Today, at the Trento GFOSS conference we saw presentations with QGIS 1.4
> in action - of course still used.
>
> Please consider to backport at least important fixes.
> Your users will be grateful.
>
> Kind regards,
> Markus Neteler
>
> --
> Markus Neteler, PhD
> Fondazione Edmund Mach (FEM) - Research and Innovation Centre
> Department of Biodiversity and Molecular Ecology
> Head of GIS and Remote Sensing Unit
> Via E. Mach, 1 - 38010 S. Michele all'Adige (TN), Italy
> Web:   http://gis.cri.fmach.it  -   http://grass.osgeo.org
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>


Although it doesn't sometimes seem like it, this is something we would
love to do. The wiki pages you point to demonstrate I have also put a
lot of thought into how to create more stablised QGIS versions. I know
we are 8 years old, but in many respects we are still an immature
project, with much work and activity taking place in implementing
basic GIS features still. I don't believe there are any of us that are
able to work full time on QGIS and we have to deal with economy of
effort and herding cats (i.e. the effect that developers will work on
what they want to work on, not what we ask them to work on). Until we
can figure out how to attract someone to maintain backports / stable
releases, I'm afraid that even with the best will in the world this
simply isnt going to happen. Later this year we are hoping to put out
QGIS 2.0 and we can try again to maintain that as a stable release. I
think using GIT will make this easier as we should be able to cherry
pick & merge upstream commits.

One thing that would be interesting would be if you could share with
us how you run GRASS development internally, and how you organise
things so that devlopers are motivated to backport fixes to stable
releases while you work on new versions?

Regards

Tim



-- 
Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
==============================================
Visit http://linfiniti.com to find out about:
 * QGIS programming services
 * Mapserver and PostGIS based hosting plans
 * FOSS Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
==============================================