[Qgis-developer] The case for bugfix releases

Sandro Santilli strk at keybit.net
Sun Sep 29 23:53:06 PDT 2013


On Mon, Sep 30, 2013 at 08:22:59AM +0200, Paolo Cavallini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Il 29/09/2013 12:48, Jrgen E. Fischer ha scritto:
> 
> > Anyway, this this is not yet set in stone as I'm currently still sorting out
> > stuff related to the 2.0 release (e.g. in OSGeo4W) - and therefore didn't have
> > time to come with draft for this.  So when this actually starts is still TBD.
> 
> Hi all.
> IMHO the new approach from Juergen should solve most of our problem. I understand
> people may need even more frequent (monthly) backporting of fixes. The only way I see
> this may become possible is to fund a small team of dedicated backporters, that can
> also take care of the prodction of binaries.

I think frequent releases mixing features and bugfixes are not going to
help those whose need is stability. Stability needs bugfix _only_ releases
as _any_ new feature mines the stability of the software.

Also, insisting in the production of binary makes the release process more
complex than it could be. Binary packaging and source releases should be
separate processes, IMHO. Some distributors already make binary packages
directly from develompent snapshots, if their policy needs frequent fixes,
core developers shouldn't care about binary packages because there are so
many different possible packages to make and all of them can be generated
by others from official source-level releases.

But developers should pay attention about keeping "stable" and "development"
branches separated and well-defined, and learn (over time, by trial and error)
to distinguish "safe" fixes for deny or accept in the stable branch(es).

> For Windows, we are discussing about improving osgeo4w to make this easier.
> This could be a reasonable investment, if shared among a group of power users, and
> would not interfere with mainstream development.

Asking package interest groups to invest in the production of those
packages is a good idea. A precedent I know of has been Regina who
run a pledgebank-based successful campaign for a PostGIS win64
package: http://www.pledgebank.com/postgis64windows

As for "backporters", stability isn't something newcomers
can take care of alone. I mean it'll still take review of patches
by core team members in order to reduce the possibility of
introducing new bugs while trying to fix more. 
A "team of dedicated backporters" formed by core committers should
avoid that problem.

--strk;


More information about the Qgis-developer mailing list