[Qgis-developer] Release schedule discussion - again

[Andreas Neumann]

Hi all,

Thanks all for joining the discussion.

My main concern, is about quality, not so much about the exact number of 
months between the releases - and I have the impression that given the 
current situation (not enough test coverage, large parts of the codebase 
untested, still large chunk of code go into master without 
QGEP/discussion/cross review) - that we cannot deliver good quality with 
such a rapid pace.

The only other software I know that has such a rapid pace of releases 
are web browsers (Google Chrome and Firefox) - but these projects have 
rather small incremental changes in between their releases and very 
rigid requirements for new additions to the code base, and large and 
comprehensive test suites. In addition they have automatic updates and 
much more financial resources than we have.

We can't build on the above things (at least not yet). In our current 
situation we have to rely more on manual user testing - and for that the 
one month testing/bug fixing phase is too short. And again - for someone 
who wants to test all of the releases - the releases happen too often. 
What's the point of releases where people don't have the time and 
resources to test them in depth - and the time to properly react on 
findings?

-------------------------------

The other thing is our long list of open bugs. I also regard many of the 
"normal" bugs as severe or at least very annoying.

For me we should take the time to have a break in feature development 
and invest more in quality - and having a slightly slower release 
schedule gives us at least a chance to do more in this respect.

We have some very good initiatives in this respect: the LTR release, the 
paid bug fixing, more donations, more tests provided, processing test 
suite will start soon, investment in documentation, etc. I am just 
asking for a slower pace to do these things properly.

Andreas



On 13.10.2015 08:46, Paolo Cavallini wrote:
> Hi all,
>
> Il 13/10/2015 01:14, Tom Chadwin ha scritto:
>> If the devs need more end users to test, then changing to a release every
>> six months, LTR every two years, would help. However, how would the devs
>> feel about patching LTRs for twice the duration they do now, and for one
>> extra non-LTR in between each? To me it sounds like significantly more work
>> to keep backporting for two years instead of one.
> the current LTR has been an experiment, and IMHO it has been a success.
> Do we really want to change schedule every 6 months?
> We know for sure there are contrasting needs, and we'll never make
> everyone happy. Some times ago, we had people complaining not being able
> to use for many months the supercool feature they have developed or paid
> for.
> I think it's mostly a matter of communicating appropriately:
> * for maximum reliability, use the LTR
> * if you need latest features, go for the latest published.
> Maybe we should state this clearly on the download page.
> On the other hand, I am with Nyall on the Qt5 (and I should add Python
> 3) issue.
>
> More below.
>
> Il 12/10/2015 23:17, Larry Shaffer ha scritto:
>
>> At Boundless we are seeing both sides of the issue: users who want only
>> the LTR and users who deploy the LTR but always work with or test the
>> latest version between deployments of the LTR. The latter group is
>> finding the current pace quite difficult to keep up with. I'm talking
>> about very large government agencies rolling out to 100s upon 100s of
>> thousands of users. They rely upon the advice of their power users who
>> are working with whatever is the current version (not just the LTR).
> This touches a *very* imprtant point: large organisations should have
> very clear that if they need a more stable release cycle, the best and
> most clever thing they should do is to fund:
> * more automated tests
> * more backfixing
> * more and earlier backporting.
> I cannot believe someone using any software in such huge numbers not
> having a few hundreds thousands bucks to properly support these needs.
>
> All the best.