[Qgis-developer] 3.0 Documentation and branching
Yves Jacolin
yjacolin at free.fr
Sat Mar 4 08:46:01 PST 2017
Hello,
First, sorry to be so quiet from so much time. Too much trip and tasks in my
flat. Let' me write a resume of the discussion.
There is two strategies in this thread:
* Release Documentation for each QGIS release
* Release Documentation for each LTR QGIS release
About the first strategy: we can't manage this one as it needs a big
documentation team that can work on new features when they come to QGIS doc
repository and we need to finalize the previous missing releases. This is
probably a long term target.
About the second strategy: this is the easiest way to manage the
documentation. But even here it's hard to document the previous feature except
if we can find time and work hard to finalize it.
Currently, we have the 2.14 LTR QGIS release and documentation. and we are
working mainly on 2.16/2.18 features.
Some developpers contribute to QGIS 3.0 documentation which means that we need
to either:
* switch to 3.0 for the documentation
* create a 2.x branch and ask someone to backport from master to this branch
The second possibility let's us release a 2.x documentation for the next QGIS
LTR (2.18) but we need someone to take care backport.
My proposition is to create this 2.x branch, work on master, add a label in
our PR/commit to let's the bakccport manager which one he should work on. We
can release a 2.18 release as soon as we finish to work on and focus on 3.x
release.
I would like to nominate Harrissou for this task ;) as he already manage such
backport on 2.14 release, of course if he accept it!
If this sounds good to everyone we can go ahead. Sorry if you already find a
consensus, but reading the thread today, I can't find a clear one but I get
some of your point of view and add it to my proposition. Harrissou, let's me
know if my proposition give too much work!
Thanks,
Y.
Le samedi 4 mars 2017, 11:00:51 CET Alexandre Neto a écrit :
> Hi Mathias,
>
> I am aware that there's no longer two master branches for QGIS. If I
> recall, this approach was used while there was some indefinition about the
> next releases. And master_2 was put to sleep as soon as possible, because
> it was a burden to maintain.
>
> For that reason I would prefer branching 2.18 documentation with backport
> fixes. But I think there might be some implications with the transitions.
>
> Anyway, I would just like to have a way to contribute to QGIS 3.0
> documentation.
>
> A sex, 3/03/2017, 17:21, Matthias Kuhn <matthias at opengis.ch> escreveu:
> > Hi Alexandre
> >
> > On 03/03/2017 05:46 PM, Alexandre Neto wrote:
> > > Hi all,
> > >
> > > Sorry to come back to this thread. But, although it seems that we will
> > > have a 2.18 documentation release, we are still blocking the
> > > documentation of new features arriving to the QGIS 3.0 Branch. And there
> > > are tons of it.
> > >
> > > So, could we adopt some strategy about this? Maybe two master branches
> >
> > There is only one master branch at the moment (master_2 was sent to the
> > happy hunting grounds a couple of months ago).
> >
> > So if the decision is to work on two branches in parallel, better work
> > on release-2_18 and master.
> >
> > If you have an eye on the qgis/release-2_18 branch and compare it to the
> > commits on documentation/master, I think backporting might indeed be
> > worth a try.
> >
> > But remember, that I've got no idea about your workflows ;)
> >
> > Matthias
> >
> > > if necessary (as done for QGIS code). Or branch 2.18 documentation, work
> > > normally in master and backport all functionalities that were missing?
> > >
> > > Any opinions or ideas?
> > >
> > > Thanks!
> > >
> > > Alexandre Neto <senhor.neto at gmail.com <mailto:senhor.neto at gmail.com>>
> > >
> > > escreveu no dia quarta, 22/02/2017 às 12:50:
> > > I can try. Although I don't have your eye for details. :-)
> > >
> > >
> > > A qua, 22/02/2017, 12:01, DelazJ <delazj at gmail.com
> > >
> > > <mailto:delazj at gmail.com>> escreveu:
> > > Hi,
> > >
> > > 2017-02-22 0:38 GMT+01:00 Alexandre Neto <senhor.neto at gmail.com
> > >
> > > <mailto:senhor.neto at gmail.com>>:
> > > According to the latest news, it seems that there will make
> > > sense to have a 2.18 Documentation release...
> > >
> > > Sorry for trying to "rush" it to 3.0. Or will it be 3.2?
> > >
> > > Anyway, I am going to put some effort in fixing 2.x issues
> > > in the user's manual.
> > >
> > > Like reviewing some of the pending pull requests? :)
> > > Thanks
> > >
> > > H.
> > >
> > > A qui, 9/02/2017, 09:39, DelazJ <delazj at gmail.com
> > >
> > > <mailto:delazj at gmail.com>> escreveu:
> > > Hi,
> > >
> > > Alexandre, Thanks for the clarification. Indeed we need
> > > to hear people once for all on this (these) topic(s) and
> > > ensure any contribution is not rejected or discouraged.
> > > And I think making PR guarantee that a contribution is
> > > taken into account (we still have a queue shorter than
> > > QGIS repo's :) )
> > >
> > > Richard, I think it's more than clear that the next
> > > application release is 3.0 and the 2.x serie is behind
> > > us now. It's also clear that after 2.14, the next LTR
> > > will be 3.2. Btw, we need to update a bit
> >
> > http://qgis.org/en/site/getinvolved/development/roadmap.html#release-sched
> > ule>
> > > The 2.x vs 3.0 issue reports separation in Doc repo was
> > > at that time due to the hypothetic release of a QGIS
> > > 2.20 which would be a LTR hence would deserve a
> > > documentation (due to the rule "only LTRs are
> > > documented"). Now there will be no 2.20 and the next LTR
> > > is two releases away so, as Richard said "the main
> > > question is: do we decide to NOT release a newer
> > > documentation(!) 2.x branch anymore this year.?" In
> > > other words: Do we keep 2.x series documentation at 2.14
> > > level, while there are 2.16 and 2.18 releases that would
> > > surely be used for a while?
> > >
> > > That's all! And I'm fine with whatever (argumented)
> > > answer is made! if the answer is a categoric No :),
> > > let's pull 3.0 fixes
> > > If the answer is "Yes, we want to release a 2.18
> > > documentation" (without translation of course), we can
> > > still begin working on 3.0 issues by creating a master_2
> > > branch for 2.18 fixes and port fixes from a branch to
> > > another. It has been made with QGIS repo. I'm sure it 'd
> > > not be that hard to maintain. It's not like if we have
> > > codes, it's all about text (more understandable and
> > > cherry-pickable for me, anyway).
> > >
> > > Btw, given that we are in dev list, allow me to remind
> > > that in the thread in psc-list, there was a call for
> > > devs to help maintain and reinforce the backend of
> > > documentation.... you are welcome... Thanks
> > >
> > > Regards,
> > > Harrissou
> > >
> > > 2017-02-09 8:36 GMT+01:00 Richard Duivenvoorde
> > >
> > > <rdmailings at duif.net <mailto:rdmailings at duif.net>>:
> > > On 08-02-17 12:42, Alexandre Neto wrote:
> > > > My concerns are about this part:
> > > >
> > > > /"Then, afaict, a part of this commit is more
> > >
> > > about QGIS 3 changes and I
> > >
> > > > am not sure we are currently documenting QGIS3
> >
> > stuffs (still waiting for
> >
> > > > comments and decision in this thread
> > >
> > > <
> >
> > https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005060.html>)."
> >
> > > > /
> > > > So, with my email, I just wanted to go back to the
> >
> > discussion of what
> >
> > > > versions we are planning/want to release and have
> >
> > a decision. Also, make
> >
> > > > sure that whatever the decision on that, we have a
> >
> > solution that does
> >
> > > > not put a developer's (or anyone else) PR on hold
> >
> > (not merged) if they
> >
> > > > want to contribute documentation for the current
> >
> > is master version.
> >
> > > > Mainly because people's availability and
> >
> > motivation can be affected by that.
> >
> > > Hi Alexandre,
> > >
> > > the main reason holding back 3.0 descriptions from
> > > master is to be able
> > > to release a (nowadays pretty theoretical?) new LTR
> > > in 2.x branch.
> > >
> > > This in case that waiting for a stable 3.x (plus a
> > > reasonable set of
> > > working python plugins!) would take too long, and
> > > the community would
> > > decide or ask for another 2.x release to be able to
> > > do their daily work
> > > with QGIS.
> > >
> > > IF we are more or less sure that there will NO MORE
> > > 2.x QGIS (LTR's?)
> > > anymore, we can decide to lift this clear 2.x - 3.x
> > > separation (thanks
> > > Harrissou for defending this :-) ).
> > >
> > > So the main question is: do we decide to NOT release
> > > a newer
> > > documentation(!) 2.x branch anymore this year.
> > >
> > > Regards,
> > >
> > > Richard
> > >
> > > --
> > > Alexandre Neto
> > > ---------------------
> > > @AlexNetoGeo
> > > http://sigsemgrilhetas.wordpress.com
> > > http://gisunchained.wordpress.com
> > >
> > > --
> > > Alexandre Neto
> > > ---------------------
> > > @AlexNetoGeo
> > > http://sigsemgrilhetas.wordpress.com
> > > http://gisunchained.wordpress.com
> > >
> > > --
> > > Alexandre Neto
> > > ---------------------
> > > @AlexNetoGeo
> > > http://sigsemgrilhetas.wordpress.com
> > > http://gisunchained.wordpress.com
> > >
> > >
> > > _______________________________________________
> > > Qgis-developer mailing list
> > > Qgis-developer at lists.osgeo.org
> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> > _______________________________________________
> > Qgis-developer mailing list
> > Qgis-developer at lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
More information about the Qgis-developer
mailing list