[Qgis-developer] Release schedule discussion - again

[Andreas Neumann]

Hi all,

So there seems to be a general agreement to invest more into quality/bug 
fixing/testing - but not so much about the release frequency.

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

I'd like to mention some more reasons for fewer releases:

* the plugins: plugin authors are more likely to test and fix their 
plugin for a new release if it isn't released every 4 months. We often 
have the case that if a user updates to a new version, that their 
favourite plugin that they need may be broken  and they'll have to wait 
several weeks until the author can fix it
* same applies for inhouse plugins that organizations maintain for 
themselves
* training material, documentation and books - have a hard time keeping 
up. If you are lucky, you'll get a book that covers 2.6 or 2.8.
* the general perception for QGIS users that they are always many 
versions behind - don't you think it is kind of frustrating for our 
users to be always several releases behind - because they need to rely 
on older versions? I remember many email threads where users have 
described a problem and we tell them that is fixed in master - what does 
it help them, if they are on the older version and supposed to use the 
LTR release in a production environment?
* testing: as I said - I believe you will get more/better testing if we 
slow down

Thanks,
Andreas

On 13.10.2015 09:28, Paolo Cavallini wrote:
> Il 13/10/2015 09:09, Andreas Neumann ha scritto:
>> 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.
> Hi Andreas,
> I agree with you, I think you touched very important points for our
> future. We discussed about this in the past, but now IMHO we are in a
> much better position, because we can think of QGIS as essentially
> feature complete (OK, we are never complete, but most people can do
> almost all they need even with the "oldish" LTR).
> So slowing down the pace of new features, and shifting the attention to
> more quality, is now more feasible than ever.
> This could be done being more rigid about acceptance of new features, e.g.:
> * always request a QEP with a proper discussion before merging (open
> questions: possibly also a vote? a consensus? by the community or by the
> PSC?)
> * only accept code with proper test coverage, and leave it pending until
> it has it.
> However, ultimately the issue is about resources: we should be able to
> communicate our [enterprise|large|power] users that investing in code
> quality is good for them. IMHO, with a couple of developers paid full
> time for this, things will improve dramatically; without that, we'll
> struggle. And all this regardless of the frequency of releases.
>
> All the best.