Re: [Qgis-developer] 3.0 Documentation and branching

[yjacolin]

I agree with this also.
Y.


Envoyé depuis mon appareil Samsung

 Message d'origine 
De : Paolo Cavallini <cavall...@faunalia.it> 
Date : 07/03/2017  07:52  (GMT+01:00) 
À : qgis-developer@lists.osgeo.org 
Objet : Re: [Qgis-developer] 3.0 Documentation and branching 

Il 07/03/2017 05:58, Nyall Dawson ha scritto:

> I think a better solution is to hook into the current
> [FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
> documentation repo. We could *require* that all developers who push a
> new feature commit have to post on the corresponding documentation
> auto-opened issue with at least very rough notes about how the feature
> is supposed to work. The documentation team could then polish these
> up, add screenshots, etc (and merge when the timing is right for the
> team). This would also keep things as easy as possible for devs so
> that they (*cough*... i mean me *cough*) have no excuse not to do it!

Agreed fully.
Thanks Nyall.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[yjacolin]

Agreed, note that you can also use the visual changelog as reference when it 
already released and you are working on the documentation.
Y.


Envoyé depuis mon appareil Samsung

 Message d'origine 
De : Alexandre Neto <senhor.n...@gmail.com> 
Date : 07/03/2017  11:21  (GMT+01:00) 
À : DelazJ <del...@gmail.com>, Nyall Dawson <nyall.daw...@gmail.com> 
Cc : qgis-developer <qgis-developer@lists.osgeo.org> 
Objet : Re: [Qgis-developer] 3.0 Documentation and branching 

Totally agree with Harrissou. A good description in the commit with the rigth 
tags  should be enough. 
Alex Neto

A ter, 7/03/2017, 10:06, DelazJ <del...@gmail.com> escreveu:
Hi,

2017-03-07 5:58 GMT+01:00 Nyall Dawson <nyall.daw...@gmail.com>:




I think a better solution is to hook into the current

[FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the

documentation repo. We could *require* that all developers who push a

new feature commit have to post on the corresponding documentation

auto-opened issue with at least very rough notes about how the feature

is supposed to work. The documentation team could then polish these

up, add screenshots, etc (and merge when the timing is right for the

team). This would also keep things as easy as possible for devs so

that they (*cough*... i mean me *cough*) have no excuse not to do it!


You are right, Nyall. 
However, I do not think that they later need to add information in the 
auto-opened issue in Doc repository. By default the generated issue is 
populated with all the information in the commit. So a really descriptive 
commit to QGIS repository with those tags should be enough. There are some very 
good (from a doc writer pov of course) commits where you only need to find the 
right place in the doc and copy paste the description with minor adjustments. 
Unfortunately, they are currently far from being the majority. On the other 
side, there still are many with simply the title (which sometimes can be 
helpful) or do use a dev language (too much cryptic?).

Also note that a verbose commit benefits to the Changelog team, when time 
comes

Harrissou


Nyall



___

Qgis-developer mailing list

Qgis-developer@lists.osgeo.org

List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer-- 
Alexandre 
Neto-@AlexNetoGeohttp://sigsemgrilhetas.wordpress.comhttp://gisunchained.wordpress.com

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Totally agree with Harrissou. A good description in the commit with the
rigth tags  should be enough.

Alex Neto

A ter, 7/03/2017, 10:06, DelazJ  escreveu:

> Hi,
>
> 2017-03-07 5:58 GMT+01:00 Nyall Dawson :
>
>
>
> I think a better solution is to hook into the current
> [FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
> documentation repo. We could *require* that all developers who push a
> new feature commit have to post on the corresponding documentation
> auto-opened issue with at least very rough notes about how the feature
> is supposed to work. The documentation team could then polish these
> up, add screenshots, etc (and merge when the timing is right for the
> team). This would also keep things as easy as possible for devs so
> that they (*cough*... i mean me *cough*) have no excuse not to do it!
>
> You are right, Nyall.
> However, I do not think that they later need to add information in the
> auto-opened issue in Doc repository. By default the generated issue is
> populated with all the information in the commit. So a really descriptive
> commit to QGIS repository with those tags should be enough. There are some
> very good (from a doc writer pov of course) commits where you only need to
> find the right place in the doc and copy paste the description with minor
> adjustments. Unfortunately, they are currently far from being the majority.
> On the other side, there still are many with simply the title (which
> sometimes can be helpful) or do use a dev language (too much cryptic?).
>
> Also note that a verbose commit benefits to the Changelog team, when time
> comes
>
> Harrissou
>
> Nyall
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

Hi,

2017-03-07 5:58 GMT+01:00 Nyall Dawson :

>
>
> I think a better solution is to hook into the current
> [FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
> documentation repo. We could *require* that all developers who push a
> new feature commit have to post on the corresponding documentation
> auto-opened issue with at least very rough notes about how the feature
> is supposed to work. The documentation team could then polish these
> up, add screenshots, etc (and merge when the timing is right for the
> team). This would also keep things as easy as possible for devs so
> that they (*cough*... i mean me *cough*) have no excuse not to do it!
>
> You are right, Nyall.
However, I do not think that they later need to add information in the
auto-opened issue in Doc repository. By default the generated issue is
populated with all the information in the commit. So a really descriptive
commit to QGIS repository with those tags should be enough. There are some
very good (from a doc writer pov of course) commits where you only need to
find the right place in the doc and copy paste the description with minor
adjustments. Unfortunately, they are currently far from being the majority.
On the other side, there still are many with simply the title (which
sometimes can be helpful) or do use a dev language (too much cryptic?).

Also note that a verbose commit benefits to the Changelog team, when time
comes

Harrissou

Nyall
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[yjacolin]

It seems we find a consensus here? Richard are you ok with this:* create 
release-2_18 branch* adapt features tracker if needed* made release-2_18 branch 
the default one* forward porting by contributor or by alexandre
I can't do this before the end of the week as I am on trip for QGIS training. 
Could someone create the branch?
Sorry if I am too fast to conclude. Feel free to give your opinion if necessary.
Thanks.
Y.


Envoyé depuis mon appareil Samsung

 Message d'origine 
De : DelazJ <del...@gmail.com> 
Date : 06/03/2017  15:26  (GMT+01:00) 
À : Matthias Kuhn <matth...@opengis.ch> 
Cc : qgis-developer <qgis-developer@lists.osgeo.org> 
Objet : Re: [Qgis-developer] 3.0 Documentation and branching 


2017-03-06 15:20 GMT+01:00 Matthias Kuhn <matth...@opengis.ch>:


Sorry, I explained badly. Pull requests are perfectly fine and desirable

and should be the standard way to contribute for everyone (including

devs). What I wanted to say is that commits (and therefore pull

requests) are preferable over issues because they are written in rst and

not md, unlike issues.


I can't disagree this time!
 

Matthias



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Paolo Cavallini]

Il 07/03/2017 05:58, Nyall Dawson ha scritto:

> I think a better solution is to hook into the current
> [FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
> documentation repo. We could *require* that all developers who push a
> new feature commit have to post on the corresponding documentation
> auto-opened issue with at least very rough notes about how the feature
> is supposed to work. The documentation team could then polish these
> up, add screenshots, etc (and merge when the timing is right for the
> team). This would also keep things as easy as possible for devs so
> that they (*cough*... i mean me *cough*) have no excuse not to do it!

Agreed fully.
Thanks Nyall.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Nyall Dawson]

On 7 March 2017 at 00:26, DelazJ  wrote:
>
> 2017-03-06 15:20 GMT+01:00 Matthias Kuhn :
>>
>>
>> Sorry, I explained badly. Pull requests are perfectly fine and desirable
>> and should be the standard way to contribute for everyone (including
>> devs). What I wanted to say is that commits (and therefore pull
>> requests) are preferable over issues because they are written in rst and
>> not md, unlike issues.
>>
> I can't disagree this time!

Been thinking about this issue Here's what I'm thinking now:

For a while I've pondered whether we should require that all
developers who push a feature also push documentation for that
feature. But after careful thought, I don't think this is a good move.
Here's some reasons why:

- good developers arent necessarily good writers, nor have good English skells
- there's a time investment in learning the documentation setup. This
may detract developers.

I think a better solution is to hook into the current
[FEATURE]/[NEEDS-DOCS] hooks which auto-open issues on the
documentation repo. We could *require* that all developers who push a
new feature commit have to post on the corresponding documentation
auto-opened issue with at least very rough notes about how the feature
is supposed to work. The documentation team could then polish these
up, add screenshots, etc (and merge when the timing is right for the
team). This would also keep things as easy as possible for devs so
that they (*cough*... i mean me *cough*) have no excuse not to do it!

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

2017-03-06 15:20 GMT+01:00 Matthias Kuhn :

>
> Sorry, I explained badly. Pull requests are perfectly fine and desirable
> and should be the standard way to contribute for everyone (including
> devs). What I wanted to say is that commits (and therefore pull
> requests) are preferable over issues because they are written in rst and
> not md, unlike issues.
>
> I can't disagree this time!


> Matthias
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[John Hawkinson]

Good documentation processes encourage documentation to land when
features land. If the process doesn't do that, QGIS will always be
falling behind.

--jh...@mit.edu
  John Hawkinson
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Matthias Kuhn]

> I do not understand your 1, 2, 3 points (actually I have some subtle
> disagreement i think :-) ) but yes, the end would be to have
> manual_en_2.14, manual_en_2.18 and master which will become
> manual_en_3.2 when released.

Please do disagree!

> And I prefer the term of forwardporting from 2.18 to master than
> backporting to avoid misunderstanding about the direction of the port.

Totally no preference from my side, commits can be ported whatever way
you prefer.

> The advantage of this is, that new features can immediately be
> documented in rst (and not only md as in the issue tracker) as soon as
> someone wants.
> 
> I still prefer pull requests (because PRs are a good way to avoid
> breakage/typos and also a kind of "what's new in QGIS?") but yes direct
> contribution from devs to doc will be possible.

Sorry, I explained badly. Pull requests are perfectly fine and desirable
and should be the standard way to contribute for everyone (including
devs). What I wanted to say is that commits (and therefore pull
requests) are preferable over issues because they are written in rst and
not md, unlike issues.

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

Tom, I agree with you that not having a documentation uptodate is a big
fail of the project. But I think it would not be that big if users were
aware of any strategy about documentation.
I think that:
- if we can release a doc concurrently with the application release (and
that's a huge target!)
- AND if users are aware that only LTR releases will be documented
- AND that there's a testing doc for non-LTR release
we would cover some gaps.

I'm not sure that the release cycle is a big problem. QGIS has gained
maturity and many features with this system. However I recall few years ago
discussion about integrating documentation as a part of any new features
from sponsors. Was that rejected? Is it followed?

Anyway, would be nice if a grant proposal could come on this side of the
project... _Harrissou dreaming..._

Harrissou

2017-03-06 14:01 GMT+01:00 Tom Chadwin :

> A quick, sweeping, unhelpful but important opinion from me (non-dev,
> non-doc-writer).
>
> Please don't think that retrospective documentation, and lack of docs for
> current release (not master, but current non-LTR release) is good, just
> because that's how it is now. This is the *biggest* failing of the QGIS
> project when stacked up against commercial alternatives. Can you imagine a
> professional software package being released without full docs?
>
> I know that we just don't have the resources to improve this to where it
> should be, but perhaps this would be an argument to slow down the release
> cycle.
>
> To make it absolutely clear: that fact that current latest release of QGIS
> doesn't have docs is a huge failure.
>
> 
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/3-0-Documentation-and-branching-tp5306770p5310924.html
> Sent from the QGIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

2017-03-06 13:41 GMT+01:00 Matthias Kuhn :

> Hello Alexandre,
>
> If I interpret your message correctly, you propose to
>
> 1. Match the branch names on QGIS-Documentation with the branch names
>of the QGIS repository
>
> 2. Only create branches for "documentation target" (read LTR) releases
>
> 3. Define one of the branches as "current translation target"
>
> For now we would therefore have
>
>  release-2_14 (translation target)
>  release-2_18
>  master (will become release-3.0 or release-3.2)
>
> Main work will be on master but backporting should be done whenever
> possible.
> Branches can be end-of-lifed as soon as LTR-period ends and branched off
> of master in parallel to the main QGIS repo.
>
> I do not understand your 1, 2, 3 points (actually I have some subtle
disagreement i think :-) ) but yes, the end would be to have
manual_en_2.14, manual_en_2.18 and master which will become manual_en_3.2
when released.
And I prefer the term of forwardporting from 2.18 to master than
backporting to avoid misunderstanding about the direction of the port.

The advantage of this is, that new features can immediately be
> documented in rst (and not only md as in the issue tracker) as soon as
> someone wants.
>
> I still prefer pull requests (because PRs are a good way to avoid
breakage/typos and also a kind of "what's new in QGIS?") but yes direct
contribution from devs to doc will be possible.

Harrissou

If we run into major merge troubles in the worst case, text can still be
> copy-pasted. That's actually the same amount than it is copying text
> from issues.
>
> Did I forget something?
>
> I think this sounds like a very good approach, I actually can't see any
> downsides.
>
> Bests
> Matthias
>
> On 03/06/2017 01:15 PM, Alexandre Neto wrote:
> > Hello all,
> >
> > This will be my last arguments in this thread. After these arguments, if
> > I fail to make myself clear, or you guys simply disagree with my point
> > of view, let's just carry on with our lives. I don't want to waste
> > people's time (at least not documenting time :-P)
> >
> > Richard Duivenvoorde >
> > escreveu no dia segunda, 6/03/2017 às 07:33:
> >
> > On 06-03-17 00:32, Alexandre Neto wrote:
> > > A dom, 5/03/2017, 21:56, Richard Duivenvoorde  > 
> > > >>
> escreveu:
> > >
> > > So do I understand correct that people want to write docs for
> > 3.0 in a
> > > 'fake'-3.0 branch, and the plan is then when master becomes
> > really 3.0
> > > all these changes will be cherry picked from that branch?
> > > Because I think that will be hard to do given those
> > branches will
> > > divert from each other, and it is already pretty hard to have
> > a good
> > > overview as of where to place pieces of info.
> > >
> > > Not sure if I followed your idea when you mention a "fake" 3.0
> branch.
> > > My idea would be to have a 2.18 branch and a master branch
> > (effectively
> > > aiming at 2.99 development).
> > > When a documenter work in a new feature description, he would do it
> > > directly on master and, if that feature was already available on
> qgis
> > > 2.18, backport that description to the 2.18 branch. If it's a
> feature
> > > that will only available on 3.0, there is no backporting to do.
> >
> > But... I do not understand. Currently we are writing 2.18 in master
> > isn't it? 2.16 is currently being translated.
> >
> >
> > Right now, master is being used to write documentation both for 2.16 and
> > 2.18 feaures. 2.14 is the version being translated in transifex. Right?
> >
> >
> > Next release of
> > documentation master will be 2.18 (as that is the next LTR according
> to
> > current QGIS release plans).
> >
> > So both (undocumented) 2.16 and (new) 2.18 features can go in
> > documentation master now (by working away the 2.16 and 2.18 milestone
> > features)
> >
> >
> > So far so good. It's true. This is our current situation.
> >
> >
> > 3.0 has to wait or be documented in the issue tracker.
> >
> >
> > This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
> > released (we have no estimate for that documentation release), or
> > writting it down in the bug tracker with no sure that the work will be
> > mergeble in the future may refrain people to documenting 3.0 new
> > features now (and probably won't do it later).
> >
> >
> > BUT.. but if it
> > is back-ported to 2.18 as you say... then it isn't a 3.0 feature
> anymore
> > is it? So can go in master now.
> >
> >
> > This would only be the case if we would have a 2.18 branch and 3.0
> > branch (which I was calling master).
> >
> >
> >
> > What I mend with a '3.0 fake branch' is that if people really really
> do
> > 

Re: [Qgis-developer] 3.0 Documentation and branching

[Tom Chadwin]

A quick, sweeping, unhelpful but important opinion from me (non-dev,
non-doc-writer).

Please don't think that retrospective documentation, and lack of docs for
current release (not master, but current non-LTR release) is good, just
because that's how it is now. This is the *biggest* failing of the QGIS
project when stacked up against commercial alternatives. Can you imagine a
professional software package being released without full docs?

I know that we just don't have the resources to improve this to where it
should be, but perhaps this would be an argument to slow down the release
cycle.

To make it absolutely clear: that fact that current latest release of QGIS
doesn't have docs is a huge failure.





-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/3-0-Documentation-and-branching-tp5306770p5310924.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

Hi all,

Hummm Alexandre.. By replying to Richard points, you made me rewrite the
message I was about to send :'(

So in short: I'm ok with the double branches and had already suggested it
in january (
https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005047.html) for
many reasons you already exposed.
If we do not begin to fix 3.0 issues (currently 180) in parallel to 2.x
last branch, we'll NEVER have 3.2 doc released in 2018. I'm pretty sure!
For the recall, since 2.14 release in july (august?), we have closed around
105 issues for 2.16 and 2.18 (remains 49 issues open i.e 1/3). I let you do
the calculation even though I know it's not linear.

Another advantage is that there are new writers knocking at the door and
the remaining issues for 2.x are imho not enough sexy and easy to begin
contributing. And these people are energy we should not let go.

Btw, Alexandre, thank you to remind me that I need to revert Victor's
commit (for compliance with 2.x) :)

Harrissou


2017-03-06 13:15 GMT+01:00 Alexandre Neto :

> Hello all,
>
> This will be my last arguments in this thread. After these arguments, if I
> fail to make myself clear, or you guys simply disagree with my point of
> view, let's just carry on with our lives. I don't want to waste people's
> time (at least not documenting time :-P)
>
> Richard Duivenvoorde  escreveu no dia segunda,
> 6/03/2017 às 07:33:
>
>> On 06-03-17 00:32, Alexandre Neto wrote:
>> > A dom, 5/03/2017, 21:56, Richard Duivenvoorde > > > escreveu:
>> >
>> > So do I understand correct that people want to write docs for 3.0
>> in a
>> > 'fake'-3.0 branch, and the plan is then when master becomes really
>> 3.0
>> > all these changes will be cherry picked from that branch?
>> > Because I think that will be hard to do given those branches
>> will
>> > divert from each other, and it is already pretty hard to have a good
>> > overview as of where to place pieces of info.
>> >
>> > Not sure if I followed your idea when you mention a "fake" 3.0 branch.
>> > My idea would be to have a 2.18 branch and a master branch (effectively
>> > aiming at 2.99 development).
>> > When a documenter work in a new feature description, he would do it
>> > directly on master and, if that feature was already available on qgis
>> > 2.18, backport that description to the 2.18 branch. If it's a feature
>> > that will only available on 3.0, there is no backporting to do.
>>
>> But... I do not understand. Currently we are writing 2.18 in master
>> isn't it? 2.16 is currently being translated.
>
>
> Right now, master is being used to write documentation both for 2.16 and
> 2.18 feaures. 2.14 is the version being translated in transifex. Right?
>
>
>> Next release of
>> documentation master will be 2.18 (as that is the next LTR according to
>> current QGIS release plans).
>>
> So both (undocumented) 2.16 and (new) 2.18 features can go in
>> documentation master now (by working away the 2.16 and 2.18 milestone
>> features)
>>
>
> So far so good. It's true. This is our current situation.
>
>
>> 3.0 has to wait or be documented in the issue tracker.
>
>
> This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
> released (we have no estimate for that documentation release), or writting
> it down in the bug tracker with no sure that the work will be mergeble in
> the future may refrain people to documenting 3.0 new features now (and
> probably won't do it later).
>
>
>> BUT.. but if it
>> is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
>> is it? So can go in master now.
>>
>
> This would only be the case if we would have a 2.18 branch and 3.0 branch
> (which I was calling master).
>
>
>>
>> What I mend with a '3.0 fake branch' is that if people really really do
>> want to write 3.0 documentation, we could do a 3.0 branch in which then
>> only new features available in 3.0 could come (while master hopefully
>> still grows and maybe splits pages with 2.18 features). When we have to
>> create the branch 2.18 then to start translating, and master will become
>> 3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
>> becomes master and we have to merge all changes from old master in that
>> one... both a considerable amount of work I think.
>>
>
> My proposal would be to do this backporting continuasly, keeping the two
> branches in sync as much as possible (except for 3.X features ofc). That
> is, any 2.16 or 2.18 feature added to documentation, would be added also,
> at the same time, to the 3.X documentation.
>
>
>>
>> > But given that every new feature (which is commited with a 'FEATURE'
>> > tag) has it's issue in the documentation issue tracker [0], why not
>> add
>> > information there? You can write full RST there, you can attache
>> > images/screendumps etc etc.
>> >
>> > If people (be it dev's or doc writers who 

Re: [Qgis-developer] 3.0 Documentation and branching

[Matthias Kuhn]

Hello Alexandre,

If I interpret your message correctly, you propose to

1. Match the branch names on QGIS-Documentation with the branch names
   of the QGIS repository

2. Only create branches for "documentation target" (read LTR) releases

3. Define one of the branches as "current translation target"

For now we would therefore have

 release-2_14 (translation target)
 release-2_18
 master (will become release-3.0 or release-3.2)

Main work will be on master but backporting should be done whenever
possible.
Branches can be end-of-lifed as soon as LTR-period ends and branched off
of master in parallel to the main QGIS repo.

The advantage of this is, that new features can immediately be
documented in rst (and not only md as in the issue tracker) as soon as
someone wants.

If we run into major merge troubles in the worst case, text can still be
copy-pasted. That's actually the same amount than it is copying text
from issues.

Did I forget something?

I think this sounds like a very good approach, I actually can't see any
downsides.

Bests
Matthias

On 03/06/2017 01:15 PM, Alexandre Neto wrote:
> Hello all,
> 
> This will be my last arguments in this thread. After these arguments, if
> I fail to make myself clear, or you guys simply disagree with my point
> of view, let's just carry on with our lives. I don't want to waste
> people's time (at least not documenting time :-P)
> 
> Richard Duivenvoorde >
> escreveu no dia segunda, 6/03/2017 às 07:33:
> 
> On 06-03-17 00:32, Alexandre Neto wrote:
> > A dom, 5/03/2017, 21:56, Richard Duivenvoorde  
> > >> escreveu:
> >
> > So do I understand correct that people want to write docs for
> 3.0 in a
> > 'fake'-3.0 branch, and the plan is then when master becomes
> really 3.0
> > all these changes will be cherry picked from that branch?
> > Because I think that will be hard to do given those
> branches will
> > divert from each other, and it is already pretty hard to have
> a good
> > overview as of where to place pieces of info.
> >
> > Not sure if I followed your idea when you mention a "fake" 3.0 branch.
> > My idea would be to have a 2.18 branch and a master branch
> (effectively
> > aiming at 2.99 development).
> > When a documenter work in a new feature description, he would do it
> > directly on master and, if that feature was already available on qgis
> > 2.18, backport that description to the 2.18 branch. If it's a feature
> > that will only available on 3.0, there is no backporting to do.
> 
> But... I do not understand. Currently we are writing 2.18 in master
> isn't it? 2.16 is currently being translated.
> 
> 
> Right now, master is being used to write documentation both for 2.16 and
> 2.18 feaures. 2.14 is the version being translated in transifex. Right?
>  
> 
> Next release of
> documentation master will be 2.18 (as that is the next LTR according to
> current QGIS release plans).
> 
> So both (undocumented) 2.16 and (new) 2.18 features can go in
> documentation master now (by working away the 2.16 and 2.18 milestone
> features)
> 
> 
> So far so good. It's true. This is our current situation.
>  
> 
> 3.0 has to wait or be documented in the issue tracker.
> 
> 
> This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
> released (we have no estimate for that documentation release), or
> writting it down in the bug tracker with no sure that the work will be
> mergeble in the future may refrain people to documenting 3.0 new
> features now (and probably won't do it later).
>  
> 
> BUT.. but if it
> is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
> is it? So can go in master now.
> 
> 
> This would only be the case if we would have a 2.18 branch and 3.0
> branch (which I was calling master).
>  
> 
> 
> What I mend with a '3.0 fake branch' is that if people really really do
> want to write 3.0 documentation, we could do a 3.0 branch in which then
> only new features available in 3.0 could come (while master hopefully
> still grows and maybe splits pages with 2.18 features). When we have to
> create the branch 2.18 then to start translating, and master will become
> 3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
> becomes master and we have to merge all changes from old master in that
> one... both a considerable amount of work I think.
> 
> 
> My proposal would be to do this backporting continuasly, keeping the two
> branches in sync as much as possible (except for 3.X features ofc). That
> is, any 2.16 or 2.18 feature added to documentation, would be added
> also, at the same time, to the 3.X documentation.
>  
> 
> 
> > But given 

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hello all,

This will be my last arguments in this thread. After these arguments, if I
fail to make myself clear, or you guys simply disagree with my point of
view, let's just carry on with our lives. I don't want to waste people's
time (at least not documenting time :-P)

Richard Duivenvoorde  escreveu no dia segunda,
6/03/2017 às 07:33:

> On 06-03-17 00:32, Alexandre Neto wrote:
> > A dom, 5/03/2017, 21:56, Richard Duivenvoorde  > > escreveu:
> >
> > So do I understand correct that people want to write docs for 3.0 in
> a
> > 'fake'-3.0 branch, and the plan is then when master becomes really
> 3.0
> > all these changes will be cherry picked from that branch?
> > Because I think that will be hard to do given those branches will
> > divert from each other, and it is already pretty hard to have a good
> > overview as of where to place pieces of info.
> >
> > Not sure if I followed your idea when you mention a "fake" 3.0 branch.
> > My idea would be to have a 2.18 branch and a master branch (effectively
> > aiming at 2.99 development).
> > When a documenter work in a new feature description, he would do it
> > directly on master and, if that feature was already available on qgis
> > 2.18, backport that description to the 2.18 branch. If it's a feature
> > that will only available on 3.0, there is no backporting to do.
>
> But... I do not understand. Currently we are writing 2.18 in master
> isn't it? 2.16 is currently being translated.


Right now, master is being used to write documentation both for 2.16 and
2.18 feaures. 2.14 is the version being translated in transifex. Right?


> Next release of
> documentation master will be 2.18 (as that is the next LTR according to
> current QGIS release plans).
>
So both (undocumented) 2.16 and (new) 2.18 features can go in
> documentation master now (by working away the 2.16 and 2.18 milestone
> features)
>

So far so good. It's true. This is our current situation.


> 3.0 has to wait or be documented in the issue tracker.


This is where, IMHO, it starts to fail. Having to wait for 2.18 to be
released (we have no estimate for that documentation release), or writting
it down in the bug tracker with no sure that the work will be mergeble in
the future may refrain people to documenting 3.0 new features now (and
probably won't do it later).


> BUT.. but if it
> is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
> is it? So can go in master now.
>

This would only be the case if we would have a 2.18 branch and 3.0 branch
(which I was calling master).


>
> What I mend with a '3.0 fake branch' is that if people really really do
> want to write 3.0 documentation, we could do a 3.0 branch in which then
> only new features available in 3.0 could come (while master hopefully
> still grows and maybe splits pages with 2.18 features). When we have to
> create the branch 2.18 then to start translating, and master will become
> 3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
> becomes master and we have to merge all changes from old master in that
> one... both a considerable amount of work I think.
>

My proposal would be to do this backporting continuasly, keeping the two
branches in sync as much as possible (except for 3.X features ofc). That
is, any 2.16 or 2.18 feature added to documentation, would be added also,
at the same time, to the 3.X documentation.


>
> > But given that every new feature (which is commited with a 'FEATURE'
> > tag) has it's issue in the documentation issue tracker [0], why not
> add
> > information there? You can write full RST there, you can attache
> > images/screendumps etc etc.
> >
> > If people (be it dev's or doc writers who are eager to dive into a
> new
> > feature) write there stuff there, it can be copied from there into
> the
> > rst of the docs as soon as we open up for 3.0 features.
> >
> > This (or having a waiting PR) is precisely what I would like to avoid,
> > because if we wait for 2.18 documentation to be finished before starting
> > document 3.0, those hanging contributions can be difficult to integrate
> > later. Besides, it will be easy for other documenters to miss those
> > contributions and do some overlapping.
> >
> > IMHO, the master branch version of documentation should (almost) always
> > match the master branch version of QGIS.
>
> Agreed... and normally this is the case.. we should not hold back adding
> features for newer versions in between LTR's. But we are in a strange
> situation currently: 2 LTR's pretty soon next to each other and a lot of
> work going into a future LTR while next LTR is already being developed
> while not yet to be released.
>
> Or do I just miss your point?
>
> Who or what makes us so eager to document the 3.0 features? Going into
> the issue tracker I see devs are using that (more or less) to write down
> some lines or 

Re: [Qgis-developer] 3.0 Documentation and branching

[Richard Duivenvoorde]

On 06-03-17 00:32, Alexandre Neto wrote:
> A dom, 5/03/2017, 21:56, Richard Duivenvoorde  > escreveu:
> 
> So do I understand correct that people want to write docs for 3.0 in a
> 'fake'-3.0 branch, and the plan is then when master becomes really 3.0
> all these changes will be cherry picked from that branch?
> Because I think that will be hard to do given those branches will
> divert from each other, and it is already pretty hard to have a good
> overview as of where to place pieces of info.
> 
> Not sure if I followed your idea when you mention a "fake" 3.0 branch.
> My idea would be to have a 2.18 branch and a master branch (effectively
> aiming at 2.99 development).
> When a documenter work in a new feature description, he would do it
> directly on master and, if that feature was already available on qgis
> 2.18, backport that description to the 2.18 branch. If it's a feature
> that will only available on 3.0, there is no backporting to do.

But... I do not understand. Currently we are writing 2.18 in master
isn't it? 2.16 is currently being translated. Next release of
documentation master will be 2.18 (as that is the next LTR according to
current QGIS release plans).
So both (undocumented) 2.16 and (new) 2.18 features can go in
documentation master now (by working away the 2.16 and 2.18 milestone
features)
3.0 has to wait or be documented in the issue tracker. BUT.. but if it
is back-ported to 2.18 as you say... then it isn't a 3.0 feature anymore
is it? So can go in master now.

What I mend with a '3.0 fake branch' is that if people really really do
want to write 3.0 documentation, we could do a 3.0 branch in which then
only new features available in 3.0 could come (while master hopefully
still grows and maybe splits pages with 2.18 features). When we have to
create the branch 2.18 then to start translating, and master will become
3.0 that 'fake 3.0 branch' should be merged back in 3.0, OR 'fake 3.0'
becomes master and we have to merge all changes from old master in that
one... both a considerable amount of work I think.

> But given that every new feature (which is commited with a 'FEATURE'
> tag) has it's issue in the documentation issue tracker [0], why not add
> information there? You can write full RST there, you can attache
> images/screendumps etc etc.
> 
> If people (be it dev's or doc writers who are eager to dive into a new
> feature) write there stuff there, it can be copied from there into the
> rst of the docs as soon as we open up for 3.0 features.
> 
> This (or having a waiting PR) is precisely what I would like to avoid,
> because if we wait for 2.18 documentation to be finished before starting
> document 3.0, those hanging contributions can be difficult to integrate
> later. Besides, it will be easy for other documenters to miss those
> contributions and do some overlapping.
> 
> IMHO, the master branch version of documentation should (almost) always
> match the master branch version of QGIS. 

Agreed... and normally this is the case.. we should not hold back adding
features for newer versions in between LTR's. But we are in a strange
situation currently: 2 LTR's pretty soon next to each other and a lot of
work going into a future LTR while next LTR is already being developed
while not yet to be released.

Or do I just miss your point?

Who or what makes us so eager to document the 3.0 features? Going into
the issue tracker I see devs are using that (more or less) to write down
some lines or images. So do you think if they can do it somewhere else
in Github that it will be better?

And I agree, a feature should be documented as soon as possible when a
dev still has the details about an implementation... but both devs and
doc writers are free to write down as much as details in the
issue-tracker of those features:

https://github.com/qgis/QGIS-Documentation/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22QGIS+3.0%22

Isn't working your way trough the QGIS 3.0 Features issues there easier
then trying to merge/back-port two git documentation branches?

And maybe I just miss info or your point. It is all about taking
responsibility for a decision, I personally do not dare to promise that
I would/could do the merging (and I have the feeling both Yves and
Harrisou have the same). But if you or somebody else has the feeling
he/she can handle it and promises to do so... we can do a 3.0 branch
(which I call 3.0 fake branch)

But then make it a 3.0 branch and do not mess up master with this info.
So IF merging appears to be too much hassle we at least have current
master then to continue?

Or else... I just do not understand :-~

Regards,

Richard
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hi Richard,

A dom, 5/03/2017, 21:56, Richard Duivenvoorde 
escreveu:

So do I understand correct that people want to write docs for 3.0 in a
> 'fake'-3.0 branch, and the plan is then when master becomes really 3.0
> all these changes will be cherry picked from that branch?
> Because I think that will be hard to do given those branches will
> divert from each other, and it is already pretty hard to have a good
> overview as of where to place pieces of info.
>

Not sure if I followed your idea when you mention a "fake" 3.0 branch.

My idea would be to have a 2.18 branch and a master branch (effectively
aiming at 2.99 development).

When a documenter work in a new feature description, he would do it
directly on master and, if that feature was already available on qgis 2.18,
backport that description to the 2.18 branch. If it's a feature that will
only available on 3.0, there is no backporting to do.

>
> But given that every new feature (which is commited with a 'FEATURE'
> tag) has it's issue in the documentation issue tracker [0], why not add
> information there? You can write full RST there, you can attache
> images/screendumps etc etc.
>
> If people (be it dev's or doc writers who are eager to dive into a new
> feature) write there stuff there, it can be copied from there into the
> rst of the docs as soon as we open up for 3.0 features.
>

This (or having a waiting PR) is precisely what I would like to avoid,
because if we wait for 2.18 documentation to be finished before starting
document 3.0, those hanging contributions can be difficult to integrate
later. Besides, it will be easy for other documenters to miss those
contributions and do some overlapping.

IMHO, the master branch version of documentation should (almost) always
match the master branch version of QGIS.


> Regards,
>
> Richard
>
> [0] As an example: https://github.com/qgis/QGIS-Documentation/issues/1723
>
> > Y.
> > Le dimanche 5 mars 2017, 00:53:53 CET Alexandre Neto a écrit :
> >> Hi Mathias,
> >>
> >> We only need to translate finished documentation. So I guess the next
> >> candidate for translation would be 2.18 Documentation once it was
> released.
> >>
> >> Richard is the guy that have it all wired up, I would like to hear from
> him
> >> if there are any nasty implications of having two branches receiving
> >> changes.
> >>
> >> A sáb, 4/03/2017, 23:05, Matthias Kuhn  escreveu:
> >>> Hi all,
> >>>
> >>> Are there any specific plans how to handle translations?
> >>>
> >>> I don't think transifex can handle multiple branches (please proof me
> >>> wrong!). So I guess a decision needs to be made from which branch
> >>> updates should be pushed to transifex. Possibly the translated files
> can
> >>> then be pulled into the other branch as well, but that sounds like
> >>> advanced magic and a good portion of luck ;)
> >>>
> >>> Matthias
> >>> ___
> >>> Qgis-developer mailing list
> >>> Qgis-developer@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@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@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Richard Duivenvoorde]

On 05-03-17 15:28, Yves Jacolin wrote:
> Hello,
> 
> As soon as we release the 2.18 we can start translation until the QGIS 3.0 
> release. So that's let some time for translator to work on this.

Yep, I agree. As soon as we have 2.18 LTR (or near LTR, I personally do
not care). We push 2.18 sources to transifex (in the same workspace as
we now do 2.16) and as long as we did not change the resource-uri's too
much, we keep most of translations.

Note that in transifex every sentence/paragraph actually has a 'key'
which is:
1) the resource key (name of the rst file)
2) the english source text

> Mathias is right: we can't handle two release atthe same time.

Theoretically we could create a second QGIS-Desktop project in
transifex, pull all translation from current project and push them to
the new branch. BUT that would mean parallel translation..
I think we do not have wo/man/power to translate two releases in parallel.

Transifex does just not have (for what we know) the tools to reuse
translations.

> About backport manager, yes it is not worth to have one if every documenter 
> do 
> its backport.

So do I understand correct that people want to write docs for 3.0 in a
'fake'-3.0 branch, and the plan is then when master becomes really 3.0
all these changes will be cherry picked from that branch?
Because I think that will be hard to do given those branches will
divert from each other, and it is already pretty hard to have a good
overview as of where to place pieces of info.

But given that every new feature (which is commited with a 'FEATURE'
tag) has it's issue in the documentation issue tracker [0], why not add
information there? You can write full RST there, you can attache
images/screendumps etc etc.

If people (be it dev's or doc writers who are eager to dive into a new
feature) write there stuff there, it can be copied from there into the
rst of the docs as soon as we open up for 3.0 features.

Regards,

Richard

[0] As an example: https://github.com/qgis/QGIS-Documentation/issues/1723

> Y.
> Le dimanche 5 mars 2017, 00:53:53 CET Alexandre Neto a écrit :
>> Hi Mathias,
>>
>> We only need to translate finished documentation. So I guess the next
>> candidate for translation would be 2.18 Documentation once it was released.
>>
>> Richard is the guy that have it all wired up, I would like to hear from him
>> if there are any nasty implications of having two branches receiving
>> changes.
>>
>> A sáb, 4/03/2017, 23:05, Matthias Kuhn  escreveu:
>>> Hi all,
>>>
>>> Are there any specific plans how to handle translations?
>>>
>>> I don't think transifex can handle multiple branches (please proof me
>>> wrong!). So I guess a decision needs to be made from which branch
>>> updates should be pushed to transifex. Possibly the translated files can
>>> then be pulled into the other branch as well, but that sounds like
>>> advanced magic and a good portion of luck ;)
>>>
>>> Matthias
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@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@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Yves Jacolin]

Hello,

As soon as we release the 2.18 we can start translation until the QGIS 3.0 
release. So that's let some time for translator to work on this.

Mathias is right: we can't handle two release atthe same time.

About backport manager, yes it is not worth to have one if every documenter do 
its backport.

Y.
Le dimanche 5 mars 2017, 00:53:53 CET Alexandre Neto a écrit :
> Hi Mathias,
> 
> We only need to translate finished documentation. So I guess the next
> candidate for translation would be 2.18 Documentation once it was released.
> 
> Richard is the guy that have it all wired up, I would like to hear from him
> if there are any nasty implications of having two branches receiving
> changes.
> 
> A sáb, 4/03/2017, 23:05, Matthias Kuhn  escreveu:
> > Hi all,
> > 
> > Are there any specific plans how to handle translations?
> > 
> > I don't think transifex can handle multiple branches (please proof me
> > wrong!). So I guess a decision needs to be made from which branch
> > updates should be pushed to transifex. Possibly the translated files can
> > then be pulled into the other branch as well, but that sounds like
> > advanced magic and a good portion of luck ;)
> > 
> > Matthias
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hi Mathias,

We only need to translate finished documentation. So I guess the next
candidate for translation would be 2.18 Documentation once it was released.

Richard is the guy that have it all wired up, I would like to hear from him
if there are any nasty implications of having two branches receiving
changes.

A sáb, 4/03/2017, 23:05, Matthias Kuhn  escreveu:

> Hi all,
>
> Are there any specific plans how to handle translations?
>
> I don't think transifex can handle multiple branches (please proof me
> wrong!). So I guess a decision needs to be made from which branch
> updates should be pushed to transifex. Possibly the translated files can
> then be pulled into the other branch as well, but that sounds like
> advanced magic and a good portion of luck ;)
>
> Matthias
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hi Yves,

Thanks for your input.

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).

If we follow this strategy, are there any implications with the translation
work?

A sáb, 4/03/2017, 18:07, Yves Jacolin  escreveu:

> 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  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  >>
> > > >
> > > > 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  > > >
> > > > > escreveu:
> > > > Hi,
> > > >
> > > > 2017-02-22 0:38 GMT+01:00 Alexandre Neto <
> senhor.n...@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 

Re: [Qgis-developer] 3.0 Documentation and branching

[Yves Jacolin]

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  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 >
> > > 
> > > 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  > > 
> > > > escreveu:
> > > Hi,
> > > 
> > > 2017-02-22 0:38 GMT+01:00 Alexandre Neto  > > 
> > > >:
> > > 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  > > 
> > > > escreveu:
> > > Hi,
> > > 
> > > Alexandre, Thanks for the clarification. Indeed we need
> > > to hear people 

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

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  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 >
> > 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  > > escreveu:
> >
> > Hi,
> >
> > 2017-02-22 0:38 GMT+01:00 Alexandre Neto  > >:
> >
> > 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  > > 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-schedule
> > 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 

Re: [Qgis-developer] 3.0 Documentation and branching

[Matthias Kuhn]

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 >
> 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  > escreveu:
> 
> Hi,
> 
> 2017-02-22 0:38 GMT+01:00 Alexandre Neto  >:
> 
> 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  > 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-schedule
> 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
> >:
> 
> On 08-02-17 12:42, Alexandre Neto wrote:
> > My concerns are about this part:
> >
> > /"Then, afaict, a part of this commit is more

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

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 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  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  escreveu:
>
> Hi,
>
> 2017-02-22 0:38 GMT+01:00 Alexandre Neto :
>
> 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  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-schedule
> 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 :
>
> 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
> > )."
> >
> > /
> > 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
> 

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

I can try. Although I don't have your eye for details. :-)

A qua, 22/02/2017, 12:01, DelazJ  escreveu:

> Hi,
>
> 2017-02-22 0:38 GMT+01:00 Alexandre Neto :
>
> 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  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-schedule
> 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 :
>
> 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
> > )."
> >
> > /
> > 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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

Hi,

2017-02-22 0:38 GMT+01:00 Alexandre Neto :

> 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  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-schedule
>> 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 :
>>
>> 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
>> > > >)."
>> >
>> > /
>> > 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
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

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.

A qui, 9/02/2017, 09:39, DelazJ  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-schedule
> 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 :
>
> 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
> > )."
> >
> > /
> > 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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

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-schedule
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 :

> 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
> > )."
> >
> > /
> > 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
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Jürgen E . Fischer]

Hi Richard,

On Thu, 09. Feb 2017 at 08:36:00 +0100, Richard Duivenvoorde wrote:
> 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 you can make a decision - just 2.x point releases ahead...


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



pgpwGZb22KaC2.pgp
Description: PGP signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hi Richard,

The hipotetical extra 2.X LTR release was the piece that I was missing.
Thanks for reminding me of that.

So, maybe I started the wrong discussion and I should be asking if we
really are going to release another LTR in 2.x branch instead.

Since there is no active development in the 2.x branch, except for bug
fixes, maybe we can assume that the feature set would be the same as 2.18?

Back to my original concern: what do we do with documentation PRs aimed at
new features in the 3.X branch?

Moreover, with the new context help mechanism (thanks Richard and Alex Bruy
for that), If the developer wants to add a help button pointing to
documentation, he/we must be able to create new sections or at least put
some placeholders for it. Otherwise we won't be able to change that after
QGIS release (releasing documentation at the same time as QGIS IMHO is
still an utopia)

I know that we are in a exceptional situation because of 3.x release date
indefinition, but I think we should allow to document the master branch at
the same time it is coded. I just don't know how can we do it.

Also let me say that I share Harrissou opinion (from another thread) that
it's a pity that documentation is often forgot in the project's plans. With
all the changes happening in 3.0 we will be in deep trouble to have a good
3.2 documentation ready.

Thanks

Alexandre

A qui, 9/02/2017, 07:36, Richard Duivenvoorde 
escreveu:

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
> )."
>
> /
> 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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Richard Duivenvoorde]

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
> )."
> 
> /
> 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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

Hello Harrissou et al.,

Sorry if I sounded too harsh. That was not my intention, at all. Neither
was my intention to point my finger to you. Intead I wanted to point to a
situation that this commit exposed. Also, I don't think no one got offended
by the comments to the commit or that it looked like people are not welcome.

I totally agree with the PR methodology. So I totally agree on your
comments on that.

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
)."*
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.

Kind Regard,

Alexandre Neto

DelazJ  escreveu no dia quarta, 8/02/2017 às 09:57:

> Hi Alexandre,
>
> First of all, sorry if ever i offended someone with my request in the
> linked commit although, after proofreading the PR and its comments, I fail
> to get the link with your real concerns in this mail.
>

> I guess we all agree that the documentation needs help from everyone. And
> none of us, I think, hesitate to remind this need and invite people to
> contribute whenever possible. I also agree that core developers are somehow
> the best interlocutors to help documenting features they develop so, when
> they are available to help, they are more than welcome.
>
> BUT I'm sorry, IMHO you took the wrong example (if ever there's one) to
> show that someone is not welcome.
>

> Nowhere in the discussion you pointed I can see a barrier to any
> contribution from core dev. What was asked is to do like most of us: make a
> pull request that can be reviewed and discussed by interested people. This
> way, we avoid breaking silently documentation build (not only the
> application repo is concerned, you know that - it has already occured) and
> ensure a contribution free of typo or mistake. I'm sure there's no need to
> replay a recent discussion on psc-list about contributing "large chunks" of
> code without any review. I mistakenly(?) thought (and was proud) that the
> option taken to proceed through PRs submission (for not obvious fixes) to
> QGIS repo was already in the DNA of QGIS-DOC contributors.
>
> This was on the form, and on the substance I have some concerns about the
> commit itself: eg, do we need to remove any mention of Taudem, including
> instructions on configuring its provider when linked to QGIS?
> Btw here's a perfect example of a core dev contribution through pull
> request, few days before the aboce mentioned commit and, covering the *same
> issue*: https://github.com/qgis/QGIS-Documentation/pull/1670 This pull
> request was being discussed. Honestly, we can't be discussing an issue, a
> way to fix things and have a related commit pushed in our back, ignoring
> that discussion.
> In brief, there are enough things to discuss and it's worth a pull request
> imo.
>
> Any other kind of action you were thinking of to help *any contributor*
> follow doc guidelines and make a great contribution?
>
> Some time ago, we decided that we are going to release documentation for
> LTR releases. That was for us to concentrate efforts for documenting those
> special releases and, as soon it's finished, branch the repo. If we keep
> trying to complete version 2.x documentation, before we even start working
> on the 3.X version, we can end up wasting efforts in documenting things
> that have already changed in master.
>
> So, IMHO, after the release and branch a QGIS LTR version, we can delay
> the documentation branching for a while to give time for a good
> documentation release, but we can't do it for too long, to avoid the
> situation mentioned above.
>
> About branches and doc releases, I have already expressed my "slight
> reluctance" on LTR-only releases (given that the next LTR is not 3.0 but
> 3.2 and is far away) so unless there's a real move from the team to push a
> bunch of fixes to QGIS 3.0 issues, i opted to keep documenting 2.x features
> (and not only 2.16) I could work on.
> A recent proposal to workaround this "issue" was exposed in (another long)
> message I sent few weeks ago (with few feedbacks) in the psc-list:
> https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005047.html
>
>
> Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting any
> feature introduced in an intermediate version (e.g. 2.16, 2.18) should be
> done, if possible, taking into account changes make to it in QGIS master
> (e.g. 2.99).
>
> I might miss it but I'm not 

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

2017-02-08 11:27 GMT+01:00 Alexander Bruy :

> Disclaimer: I'm not a documentation writer, so feel free to ignore my
> comments.
>
> Me neither. I'm not in charge of anything in the documentation so my
comments had no more weight than any other member of the community.


> 2017-02-08 11:57 GMT+02:00 DelazJ :
> > Nowhere in the discussion you pointed I can see a barrier to any
> > contribution from core dev. What was asked is to do like most of us:
> make a
> > pull request that can be reviewed and discussed by interested people.
> This
> > way, we avoid breaking silently documentation build (not only the
> > application repo is concerned, you know that - it has already occured)
> and
> > ensure a contribution free of typo or mistake.
>
> Personally I see no sense in passing ALL edits via pull-request mechanism.
> While this makes sense for huge edits which add a lot of new text, creating
> a PR for small edits or removals of obsolete part of documentation looks
> like
> overhead for me.
>
> Quoting myself: "I mistakenly(?) thought (and was proud) that the option
taken to proceed through PRs submission (*for not obvious fixes*) to QGIS
repo was already in the DNA of QGIS-DOC contributors."

Harrissou

> This was on the form, and on the substance I have some concerns about the
> > commit itself: eg, do we need to remove any mention of Taudem, including
> > instructions on configuring its provider when linked to QGIS?
>
> As I already said, I see no sense in keeping instructions for 3rd
> party/external
> tools in the QGIS User Guide. Those should be part of the that 3rd party
> tool
> manual.
>
> --
> Alexander Bruy
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[Alexander Bruy]

Disclaimer: I'm not a documentation writer, so feel free to ignore my comments.

2017-02-08 11:57 GMT+02:00 DelazJ :
> Nowhere in the discussion you pointed I can see a barrier to any
> contribution from core dev. What was asked is to do like most of us: make a
> pull request that can be reviewed and discussed by interested people. This
> way, we avoid breaking silently documentation build (not only the
> application repo is concerned, you know that - it has already occured) and
> ensure a contribution free of typo or mistake.

Personally I see no sense in passing ALL edits via pull-request mechanism.
While this makes sense for huge edits which add a lot of new text, creating
a PR for small edits or removals of obsolete part of documentation looks like
overhead for me.

> This was on the form, and on the substance I have some concerns about the
> commit itself: eg, do we need to remove any mention of Taudem, including
> instructions on configuring its provider when linked to QGIS?

As I already said, I see no sense in keeping instructions for 3rd party/external
tools in the QGIS User Guide. Those should be part of the that 3rd party tool
manual.

-- 
Alexander Bruy
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 3.0 Documentation and branching

[DelazJ]

Hi Alexandre,

2017-02-07 18:18 GMT+01:00 Alexandre Neto :

> In my opinion, we need to take action to make sure that a developer that
> is working on a master version feature is not prevented from documenting it
> because the documentation team is still working on the 2.16 version issues.
> Example:
>
> https://github.com/qgis/QGIS-Documentation/commit/4e15534664
> 1d17a532755f535ff363b355327c91
>
> Documentation needs all the help it can get. If we expect core developer
> to help with documentation, the only time this is remotely possible is when
> they are making changes to QGIS master. For that reason, QGIS Documentation
> and QGIS master branches must be in sync regarding the version.
>
> First of all, sorry if ever i offended someone with my request in the
linked commit although, after proofreading the PR and its comments, I fail
to get the link with your real concerns in this mail.

I guess we all agree that the documentation needs help from everyone. And
none of us, I think, hesitate to remind this need and invite people to
contribute whenever possible. I also agree that core developers are somehow
the best interlocutors to help documenting features they develop so, when
they are available to help, they are more than welcome.

BUT I'm sorry, IMHO you took the wrong example (if ever there's one) to
show that someone is not welcome.

Nowhere in the discussion you pointed I can see a barrier to any
contribution from core dev. What was asked is to do like most of us: make a
pull request that can be reviewed and discussed by interested people. This
way, we avoid breaking silently documentation build (not only the
application repo is concerned, you know that - it has already occured) and
ensure a contribution free of typo or mistake. I'm sure there's no need to
replay a recent discussion on psc-list about contributing "large chunks" of
code without any review. I mistakenly(?) thought (and was proud) that the
option taken to proceed through PRs submission (for not obvious fixes) to
QGIS repo was already in the DNA of QGIS-DOC contributors.

This was on the form, and on the substance I have some concerns about the
commit itself: eg, do we need to remove any mention of Taudem, including
instructions on configuring its provider when linked to QGIS?
Btw here's a perfect example of a core dev contribution through pull
request, few days before the aboce mentioned commit and, covering the *same
issue*: https://github.com/qgis/QGIS-Documentation/pull/1670 This pull
request was being discussed. Honestly, we can't be discussing an issue, a
way to fix things and have a related commit pushed in our back, ignoring
that discussion.
In brief, there are enough things to discuss and it's worth a pull request
imo.

Any other kind of action you were thinking of to help *any contributor*
follow doc guidelines and make a great contribution?

Some time ago, we decided that we are going to release documentation for
> LTR releases. That was for us to concentrate efforts for documenting those
> special releases and, as soon it's finished, branch the repo. If we keep
> trying to complete version 2.x documentation, before we even start working
> on the 3.X version, we can end up wasting efforts in documenting things
> that have already changed in master.
>
> So, IMHO, after the release and branch a QGIS LTR version, we can delay
> the documentation branching for a while to give time for a good
> documentation release, but we can't do it for too long, to avoid the
> situation mentioned above.
>
> About branches and doc releases, I have already expressed my "slight
reluctance" on LTR-only releases (given that the next LTR is not 3.0 but
3.2 and is far away) so unless there's a real move from the team to push a
bunch of fixes to QGIS 3.0 issues, i opted to keep documenting 2.x features
(and not only 2.16) I could work on.
A recent proposal to workaround this "issue" was exposed in (another long)
message I sent few weeks ago (with few feedbacks) in the psc-list:
https://lists.osgeo.org/pipermail/qgis-psc/2017-January/005047.html


> Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting any
> feature introduced in an intermediate version (e.g. 2.16, 2.18) should be
> done, if possible, taking into account changes make to it in QGIS master
> (e.g. 2.99).
>
> I might miss it but I'm not aware of any feature recently documented that
was removed in 3.0. And I agree that this is something to take into
consideration.

Kind Regards,
Harrissou

2017-02-07 18:29 GMT+01:00 Paolo Cavallini :

> Ola Alexandre,
>
> Il 07/02/2017 18:18, Alexandre Neto ha scritto:
>
> > So, IMHO, after the release and branch a QGIS LTR version, we can delay
> > the documentation branching for a while to give time for a good
> > documentation release, but we can't do it for too long, to avoid the
> > situation mentioned above.
> >
> > Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting
> 

Re: [Qgis-developer] 3.0 Documentation and branching

[Paolo Cavallini]

Ola Alexandre,

Il 07/02/2017 18:18, Alexandre Neto ha scritto:

> So, IMHO, after the release and branch a QGIS LTR version, we can delay
> the documentation branching for a while to give time for a good
> documentation release, but we can't do it for too long, to avoid the
> situation mentioned above.
> 
> Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting
> any feature introduced in an intermediate version (e.g. 2.16, 2.18)
> should be done, if possible, taking into account changes make to it in
> QGIS master (e.g. 2.99).

seems fine to me - any objection?
All the best, and thank you for raising the issue.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] 3.0 Documentation and branching

[Alexandre Neto]

In my opinion, we need to take action to make sure that a developer that is
working on a master version feature is not prevented from documenting it
because the documentation team is still working on the 2.16 version issues.
Example:

https://github.com/qgis/QGIS-Documentation/commit/4e155346641d17a532755f535ff363b355327c91

Documentation needs all the help it can get. If we expect core developer to
help with documentation, the only time this is remotely possible is when
they are making changes to QGIS master. For that reason, QGIS Documentation
and QGIS master branches must be in sync regarding the version.

Some time ago, we decided that we are going to release documentation for
LTR releases. That was for us to concentrate efforts for documenting those
special releases and, as soon it's finished, branch the repo. If we keep
trying to complete version 2.x documentation, before we even start working
on the 3.X version, we can end up wasting efforts in documenting things
that have already changed in master.

So, IMHO, after the release and branch a QGIS LTR version, we can delay the
documentation branching for a while to give time for a good documentation
release, but we can't do it for too long, to avoid the situation mentioned
above.

Also, IMHO, after documentation LTR branching (e.g. 2.14), documenting any
feature introduced in an intermediate version (e.g. 2.16, 2.18) should be
done, if possible, taking into account changes make to it in QGIS master
(e.g. 2.99).

Cheers,

Alexandre Neto
-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer