[Qgis-developer] Stress about release plans

[Tim Sutton]

-----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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tim.vcf
Type: text/x-vcard
Size: 213 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140723/4ab5c098/attachment.vcf>