[Qgis-user] Stress about release plans

[Larry Shaffer]

Hi,

I don't think splitting development resources to maintain an LTS branch is
going to solve the real issues. In fact, it will probably just cause more.

It seems to me that it all boils down to needing more time between releases:

* Documentation and development teams need to work more together = more
time needed
* Developers need to squash more bugs = more time (and funding) needed
* Users and trainers need to fully adopt and use a specific version = more
time needed

I propose just extending the current 4 month release scenario to ** 6
months **, i.e. just two releases a year. With all dev and freeze cycles
expanding proportionally.

Surely, knowing that QGIS is only/always released twice a year is enough to
tailor training and course material and help the documentation team keep
current. Surely, having more time to polish the code base and squash bugs
will help with stability.

Why do developers need a faster schedule than 6 months to produce new
features quicker if the rest of the community finds that too fast, and
can't keep up? What's the point then?

With more time and resources focusing on one (and only one) branch, we
should be able to overcome the current situation that is causing
complications for users, trainers, documenters, translators and sponsors.
Splitting dev resources between different branches, or only doing extra bug
fixing at certain times of the year will not fix these ongoing issues of
the development-release cycle going too fast for the rest of the community.

The current, too-quick 4-month release schedule is obviously NOT working
out.

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota


On Tue, Jul 22, 2014 at 3:10 PM, Bernd Vogelgesang <bernd.vogelgesang at gmx.de
> wrote:

>  Am 22.07.2014, 12:16 Uhr, schrieb Derek Hohls <dhohls at csir.co.za>:
>
>
> Is it not possible to require an absolutely minimum entry, at the correct
> place in the  docs, for a new feature?  For example, if a developer adds a
> new function X to a list of existing functions, already documented in
> section M.N, then at a minimum they need to add an entry saying "Function X
> (added 22/7/14): TBD".  Anyone wanting to contribute to the docs can then
> (hopefully) easily search for undocumented features, both recent or
> ancient.  It may even be possible to organise "doc sprints" based on this
> approach.
>
> +1 !
>
>
>
>
>
> >>> Victor Olaya <volayaf at gmail.com> 07/22/14 12:02 PM >>>
>
>
>> The solution is very simple: Require up to date, accurate documentation
>> for all commits of new features. This is one for the PSC.
>> After all, what's the point in having tons of features if no-one knows
>> how to use them or what they do?
>> Will it slow down new feature feature commit? Probably, but I figure
>> that's a small price to pay for actually having documentation. And from
>> that documentation, universal training materials can be developed much more
>> easily.
>>
>
> -1 from me. Features are also  documented by people using them, not just
> by the devs. We like to say that you can contribute to open source projects
> not just by coding, but if we do that, I don't think we are going to get
> many contributions from users, leaving the documentation to be written only
> by developers.
>
> I try to keep the Processing documentation up to date, but only
> documenting the interface itself and the framework, not the algorithms.
> That's the reason why a large part of algorithms in Processing are not
> documented. Fortunately, some users have contributed documentation, and
> they have added descriptions of several algorithms, but the have done that
> *after* using the (hitherto undocumented) algorithm and becoming familiar
> with it. No one is going to document something that he cannot use yet.
>
> Let's encourage developers to commit features when they are well
> documented, but let's also give some flexibility, since that's not always
> going to be possible.
>
>
>
> --
> This message is subject to the CSIR's copyright terms and conditions,
> e-mail legal notice, and implemented Open Document Format (ODF) standard.
> The full disclaimer details can be found at
> http://www.csir.co.za/disclaimer.html.
>
>
> This message has been scanned for viruses and dangerous content by
> *MailScanner* <http://www.mailscanner.info/>,
> and is believed to be clean.
>
>
> Please consider the environment before printing this email.
>
>
>
>
> --
> Bernd Vogelgesang
> Siedlerstraße 2
> 91083 Baiersdorf/Igelsdorf
> Tel: 09133-825374
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20140722/e94d364e/attachment.html>