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