[Qgis-developer] Is the new release schedule a success?

[Martin Dobias]

Hi Tom

On Wed, Jul 1, 2015 at 7:36 PM, Tom Chadwin <tom.chadwin at nnpa.org.uk> wrote:
> If the answer is that there is no way that the 2.8.0 and 2.10.0 bugs would
> ever have come to light before release, then sure, I accept the argument.
> However, Nyall says that one of the bugs was apparent as a test failure.
> Perhaps the best thing to do would have been to acknowledge that the flood
> of test failures (mostly false negatives) needed to be addressed before the
> release, and so the release should have been postponed.

I would say often it is a matter of luck - sometimes we end up
releasing a solid x.x.0 version, sometimes there are quick bugfix
releases needed. Postponing a release does not really solve anything -
there is still a chance that a critical bug will be found just few
hours after a release.


> While I mean what I said about our organization's use of QGIS
> (Northumberland National Park Authority), other partner organizations (the
> other UK National Park Authorities) are often less enthusiastic about what
> they see as a risky migration to FOSS. My main point in raising this is that
> the immediate requirements for patching .0 releases adds to this reluctance.
>
> I would also disagree that FOSS users expect this. That used to be true when
> FOSS users were all enthusiastic hobbyists or devs. QGIS is a million miles
> beyond that, and is rightly challenging proprietary GISes in corporate
> environments. While I might ask our GIS officer to use the nightly build and
> report bugs, it's not his core job, nor other professional GIS officers'. He
> would struggle to find the time. Also, neither he nor I are developers, so
> there is an intimidating learning curve even in bug reporting and testing.

That is exactly why we have introduced long-term releases (LTR) for
QGIS - for organizations that just need a stable QGIS for their work,
without having to worry about instabilities, testing and reporting
bugs. And of course there are various companies in the QGIS community
which offer support and fixing of bugs, should you encounter any in
your workflow.


> My original thought was that perhaps a better release roadmap would be
> functionality-based rather than calendar-based - in other words, decide what
> the dev priorities are, and release only when agreed milestones are reached.
> Of course, the user base should be given indicative timescales, but the
> deadlines should never trump QA.

We used feature-based releases before, producing new version of QGIS
when certain milestones were reached - and it didn't work that well:
- there were times with no new release for a year (a long time for many)
- hard to find consensus when is the right time to release (there will
be always voices for releasing ASAP and voices for delaying the
release)


> Once again, of course I accept and understand that there are so few devs and
> testers compared to the user base. My point is that that is a block to the
> growth of the software which should be discussed, and therefore should not
> simply be accepted as a given.
>
> Thanks again, everyone. I'm only raising because I believe that adoption of
> QGIS might suffer because of it.

I can understand your concerns, I hope though that LTRs solve them
already to a great degree - please correct me if I am wrong.

Regards
Martin