[Qgis-psc] A plea for backporting

[Markus Neteler]

Hi Tim, all,

On Wed, Feb 16, 2011 at 10:49 AM, Tim Sutton <tim at linfiniti.com> wrote:
> On Fri, Feb 11, 2011 at 11:59 PM, Markus Neteler <neteler at osgeo.org> wrote:
...
>> So, why are backports of (important) bugfixes needed?

I forgot to mention that the poll winner was "fixing bugs" at
http://www.qgis.org/en/component/content/article/56/119-kcube-poll.html


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

No need to downgrade the excellent project :)

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

I know perfectly what you mean - same thing in the GRASS project,
and QGIS may have even more developers.

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

I agree - but only because it is IMHO the wrong direction. Of course
it is too time and energy consuming to have a dedicated person
managing the backports, things would have to be explained and such.
In the GRASS project the individual developer who fixed a bug *also*
does the backport. Nothing to explain to anyone else - s/he is the best
person to know if it is relevant or not.
Still we have the real-time commit mailing list and can discuss if a
backport is too problematic or not (this regularly happens) and eventually
revert it in such case.
Again: no dedicated person needed - indeed it is in the responsibility of
the individual developer.

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

I dunno how GIT is related to that - we happily merged with old CVS and
for some years we do so with SVN. The "meld" tool is also handy.

> 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?

Sure: most just do it. A few relevant developers don't but since they contribute
great stuff to trunk, Martin Landa, me and maybe someone else take care
of backporting things for them. The workload is fairly low if you do it
immediately. I am speaking of minutes maybe not hours. So, it is just a
matter of doing things, luckily pushing is usually not needed. And we gain
a really stable GRASS 6.4.x release branch from that.

Cheers
Markus