[Qgis-developer] Stress about release plans

Wed Jul 23 00:14:25 PDT 2014

Hi,
I like to add my opinion just to remeber that QGIS is using many other compoent.
One as example for many : gdal or geos.
But I coud speak equally of spatialite, saga, and so on.

You question are all right.
But speak always of qgis as a unique molotithic software.This is not true.

sometime the problem is not on qgis software , but in other way (gdal,
geos, spatialite, and so on...)

so what happened when the bug is related to geos ?
of to gdal ?

The bug fixer of qgis could only say.

This is not my question.

But for the user that fund the bg fix the problem is a qgis problem.
It has not fund the resolution on gdal or on geos.

So before to fund is necessary to know where is the problem really.
Otherwise the fund is lost.

Or bad-est solution the bug fixer try to copy the code inside the qgis
to bug fixe that copy.

So the bugfix of a software like qgis is absolutely not easy.

develope new feature is surely ore easy rather than fix them.

And the not monolithic approach of qgis is not help the bug fix question.

Regards,

Andrea.

2014-07-23 7:47 GMT+02:00 Tim Sutton <tim at kartoza.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi
>
> On 22/07/2014 22:50, Bo Victor Thomsen wrote:
>> Just to stretch my point -
>>
>> * I'm not argumenting for a "regular" LTS version in parallel with
>> a development version including back-porting and patching to
>> several versions of QGIS. I have developed software for 30 years; I
>> know the efforts and pains of parallel versions :-/ * I'm trying to
>> make a case for taking every *third* development cycle and
>> *minimizing* the addition of new features in this cycle and
>> *maximizing *the bug fixing/testing/documentation effort.
>
> Right this is what I have proposed in the past (e.g.
> https://www.mail-archive.com/qgis-developer@lists.osgeo.org/msg22449.html).
> I think that keeping our current release cadence and just attaching
> special criteria (e.g. only one month of feature commits, 3 months bug
> fixing and feature freeze) to intermittent releases is the simplest
> way to provide a yearly 'stable' version of QGIS without needing to
> change developer behaviour or require any more resources.
>
>
>> * Have a "clean-up" period for around one  month after the
>> "bug-fix" version release. In this period every new bug fix should
>> be added to both the "bug-fix" release and the new developer
>> release (OK, some parallel patching to 2 QGIS versions).
>
> We have been working on getting one paid developer day for
> stabilisation and release work pre month for the next 9 months via the
> InaSAFE project. If others could club together and do the same, I
> believe it could make a huge impact on the stability of QGIS with
> rather small investment by individual organisations. There are many
> god developers on our team that are available for such work and life
> will be much easier for them if they can put aside some time to work
> on stabilisation without needing to worry about how to keep their
> lights on.
>
>> * After the clean-up period there would be a mandatory point
>> release of the "bug-fix" release. And after that: No further work
>> on this "bug-fix" version.
>
> Juergen has already tabled an approach for doing bugfix releases after
> backports/bugfixes have been made to the current release branch (and
> no bugfix release if no backports / bugfixes have been made). He can
> explain better the concept, but it really needs also some impetus from
> those sponsoring developers to do work to also request that the
> bugfixes they sponsor get backported.
>
>>
>> We can discuss the details and length of the different periods. But
>> the main points is for every third development cycle: A minimum of
>> new features and a maximum effort in
>> bug-fixing/testing/translation/tutorials/documentation, i.e: all
>> the "secondary" efforts in making good and stable software. With
>> the current cycle periods there would be one "bug-fix" version
>> every year. This period coincide - in my experience - with the
>> minimum accepted time periods between software version updates in
>> most large organisations.
>
> I would like to mention that although it may not seem like it
> sometimes (mostly because of the fact that we have had this discussion
> so many times and any particular approach we take someone always has a
> big issue with), the QGIS team *are* very interested in getting a high
> quality and stable release into play, we just need to balance that
> with the fact that a) developers are largely undirected by the central
> project and focus on things they or their clients are interested in
> and b) we have extremely limited resources and much of the core
> project work is undertaken on a voluntary basis by a handful of team
> members. So any suggested route has to take into the account that you
> are asking already overstretched volunteers to take on more work,
> possibly diluting their efforts further on other areas of the project.
>
> So yes throwing money at the problem does not necessarily solve all
> problems, but it certainly will help us actually manage the parts of
> the project where volunteer time is limited and we can contract devs
> in to do important work on a paid basis. If other organisations and
> QGIS user groups could help to get just two or three devs to have a
> week of each month funded to stabilise QGIS the community at large
> would realise huge benefits as would those funding that work.
>
> Regards
>
> Tim
>
>
>>
>> Regards Bo Victor Thomsen
>>
>>
>>
>>
>> _______________________________________________ Qgis-developer
>> mailing list Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> - --
> - ------------------------------------------------------
>
> Tim Sutton
> Visit http://kartoza.com to find out about open source:
>  * Desktop GIS programming services
>  * Geospatial web development
>  * GIS Training
>  * Consulting Services
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
> - ------------------------------------------------------
> Kartoza is a merger between Linfiniti and Afrispatial
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlPPTIAACgkQqk07qZdiYjdF5wCeKjvu9HUfxqsJcVtsF5tf59X8
> NzIAn1zscMJKZ7tF3/uOPDPw9ddKD05g
> =POer
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------