[Qgis-psc] Draft announcement re 3.0
Tim Sutton
tim at kartoza.com
Sun Feb 7 23:03:09 PST 2016
Hi
On Mon, Feb 8, 2016 at 8:25 AM, Andreas Neumann <a.neumann at carto.net> wrote:
> Hi Tim,
>
> Thank you for the draft!
>
> One issue I have is the term "master branch" - which perhaps could be made
> clearer, less ambiguous.
>
Master branch = the branch called 'master' in GIT - I will add that as a
clarification.
>
> Is there only one "master branch" at any time or will there be two
> parallel "master branches"
>
> - a 2.x one and a 3.x one? Normally, I would assume that there can be only
> one master branch at any given time - e.g. 2x will stay master branch until
> 2.16 and then 3.0 would be the master branch. Or can there be two parallel
> master branches?
>
Its a direct reference to the Git branch name, so yes only one 'master'
branch/'. The other branch will be called '3.0' unless Jürgen likes to
follow GitFlow like terminology and call it 'develop'.
>
> One statement i don't like is "only for 3.x: not knowing when that will
> ever release or" --> could we rather say "only for 3.x: not knowing when
> this will release or" (take out the word "ever")
>
> I assume that we think that 3.x will happen, but we don't know when. The
> current wording seems to imply that the PSC has doubts if 3.x will ever
> happen - which I don't think is the case. But since this "o-tone Jürgen", I
> don't know if you want to change this ...
>
>
Yes that is a verbatim quote from Jürgen - I can edit it out if you feel
it muddies the waters and add an ellipsis instead ("[...]")...ok with you
Jürgen?
Thanks for your feedback!
Regards
Tim
> Andreas
>
>
> On 07.02.2016 22:56, Tim Sutton wrote:
>
> Hi PSC
>
> I have written up a draft announcement about the 3.0 plan. I am including
> a complete draft below.. Please let me know if you have comments,
> corrections, additions to this DRAFT so that I can post it and then
> advertise it more broadly.
>
> COPY BEGINS
> — ——— — ————
>
>
> QGIS 3.0 plans
>
> Ok so quick spoiler here: there is no QGIS 3.0 ready yet, nor will there
> be a QGIS 3.0 for some time. This article provides a bit more detail on the
> plans for QGIS 3.0. A few weeks ago I wrote about some of the
> considerations for the 3.0 release, so you may want to read that first
> <http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/> before
> continuing with this article as I do not cover the same ground here.
>
> A *lot* of consideration has gone into deciding what the approach will be
> for the development of QGIS 3.0. Unfortunately the first PSC
> vote regarding which proposal to follow was a split
> <https://www.loomio.org/d/5MCdPwoL/vote-to-approve-the-process-for-qgis-3-0> decision
> (4 for, 3 against, 1 abstention and 1 suggestion for an alternative in the
> discussion). During our PSC meeting this week we re-tabled the topic and
> eventually agreed on Jürgen Fischer's proposal (Jürgen is a QGIS PSC Member
> and the QGIS Release Manager) by a much more unanimous margin of 8 for, 1
> neutral and 1 absent. Jürgen's proposal is largely similar to the Proposal
> 2 described in my previous posting
> <http://blog.qgis.org/2016/01/17/help-us-to-plan-for-qgis-3-0/>. I want
> to make some special notes here about our discussion and subsequent
> decision which will hopefully help to clarify the thinking behind our
> decision for other interested observers. First let me lay out Jürgen's
> plan in his own words:
>
> "My preferred approach would still be:
>
> - Do a Qt5/PyQt5/Python3 branch in parallel, actually work on it until
> it's ready, make it master and release it as 3.0
> - Meantime keep working on master (2.x) and keep releasing them every
> 4 months as usual
>
> Everyone can work on the branch (s)he wants (or is hired to), but needs to
> consider if (s)he want to do it (or spend funds on):
>
> - only for 2.x: knowing that it will be released soon; but might
> become unusable because platforms drop support for stuff it depends on
> sooner or later
> - only for 3.x: not knowing when that will ever release or
> - for both: knowing that work needs to be done twice.
> - People adding features to the master branch will be responsible to
> ensure that their work gets merged to 3.0 branch.
>
> As PSC we should maintain the environment for people to do something for
> QGIS - but we cannot tell them to - so we don't have resources we can
> actually plan with and that means we can either release something when the
> big thing is ready or what we have in fixed intervals." - Jürgen Fischer
>
> What follows are some further details and clarifications to our preferred
> approach:
>
> *Why do parallel development?*
>
> Parallel development of 3.0 maintaining our master branch with 2.x code in
> it has advantages and disadvantages. First the advantages:
>
> - If we encounter major technical difficulties / release blockers in
> the 3.0 branch, it will not impact on our normal 3 monthly release cycle.
> - Our binary build systems (Linux, Windows and OSX binaries) will be
> unaffected until 3.0 is ready.
> - It is very likely that building 3.0 binaries on different platforms
> is going to have difficulties for each platform. For example OSGEO4W has no
> Python3 and Qt5 packages yet. Someone needs to see to the creation of the
> required package as a separate exercise from the actuals development of a
> version of QGIS that will take advantage of these updated libraries. We
> don't yes know what problems may be in countered in preparing these.
> - "Don't break what already works": we have a working and relatively
> stable master branch and we don't want to do a 'cowboy stunt' and break it.
> We prefer to wait until the 3.0 branch is mature, has passing tests and is
> known to work well before merging it into master and treating it as our
> 'best we currently have' master branch.
>
> Of course nothing in life is completely easy, there are also some
> disadvantages*:*
>
> - Some developers may feel that running two mainstream branches is
> dilution of effort. To counter this, our public recommendation is that
> after 2.16 comes out, all QGIS contributors are *strongly encouraged* to
> provide their patches against the 3.0 branch. Any features applied to the
> master branch is *not guaranteed* to be part of the 3.0 release.
> - Regular merging of master to the 3.0 branch may prove more and more
> difficult over time as the two branches diverge more. Again we will
> strongly encourage that developers submitting new features after the 2.16
> release do so against the 3.0 branch.
> - 3.0 branch won't have auto build system for nightly binaries in the
> beginning. Since we expect that the initial branch of 3.0 will break these
> anyway, Having a separate branch is actually an advantage here as it will
> give binary packages some time to get their build systems up to speed.
>
>
> *The schedule will not be fixed:*
>
> One thing that we want to make really clear (and was a key point in our
> many discussions) is that there will be no fixed release date for QGIS
> version 3.0. There are several reasons for this:
>
> - As a steering committee, we can only set the QGIS ship pointing in a
> given direction, our power to actually make work happen is extremely
> limited. This is because we are a community made up largely of volunteer
> developers or developers working on a commission basis for third party
> clients. We have no say in how these contributors spend their time.
> - We do not yet know which (if any) major technical issues will be
> encountered during the development of 3.0. Any such issues could very well
> delay the roll our of QGIS 3.0.
>
> Instead our plan is to make the 2.16 release and then effectively move all
> developer effort to the 3.0 branch as best we can (through close liaison
> with our developer community).
>
>
> *Looking forward to 3.0*
>
> Personally I am very much looking forward to the release of QGIS 3.0 - it
> represents another huge milestone in our project, it affords us a great
> opportunity to get rid of a lot of cruft out of our code base and API's and
> it will arm us with a set of modern, new libraries that will see us through
> the next several years. Rock on QGIS 3.0!
>
>
> [image: timsutton]
>
> QGIS PSC Chairman
>
> ——————
>
> COPY ENDS
> —
>
>
>
>
> Tim Sutton
>
> Visit <http://kartoza.com>http://kartoza.com to find out about open
> source:
>
> * Desktop GIS programming services
> * Geospatial web development
> * GIS Training
> * Consulting Services
>
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
>
> Kartoza is a merger between Linfiniti and Afrispatial
>
>
>
> _______________________________________________
> Qgis-psc mailing listQgis-psc at lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc
>
--
------------------------------------------------------------------------------------------
Tim Sutton
Visit http://kartoza.com to find out about open source:
* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee
-------------------------------------------------------------------------------------------
Kartoza is a merger between Linfiniti and Afrispatial
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160208/25d799e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5931 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160208/25d799e1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 9324 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160208/25d799e1/attachment-0001.png>
More information about the Qgis-psc
mailing list