GnuCash page Documentation Update Instructions has been changed by Sunfish62

[Chris Good]

> -----Original Message-----
> From: Geert Janssens [mailto:geert.gnucash at kobaltwit.be]
> Sent: Saturday, 28 January 2017 8:05 PM
> To: Chris Good <chris.good at ozemail.com.au>
> Cc: 'David T.' <sunfish62 at yahoo.com>; gnucash-devel at gnucash.org
> Subject: Re: GnuCash page Documentation Update Instructions has been
> changed by Sunfish62
> 
> Op zaterdag 28 januari 2017 10:19:44 CET schreef Chris Good:
> > > -----Original Message-----
> > > From: David T. [mailto:sunfish62 at yahoo.com]
> > > Sent: Friday, 27 January 2017 9:04 PM
> > > To: Geert Janssens <geert.gnucash at kobaltwit.be>
> > > Cc: gnucash-devel at gnucash.org; Chris Good
> > > <chris.good at ozemail.com.au>
> > > Subject: Re: GnuCash page Documentation Update Instructions has been
> > > changed by Sunfish62
> > >
> > > Geert,
> > >
> > > Thanks as always for providing a clear explanation of the situation.
> > > You have gently shown me where I have misunderstood the process, and
> > > make it clearer to me.
> > >
> > > I have entered a version that I think does a reasonable job of
> > > promoting
> > > git- maint as the commonly-used mode, but also explaining when
> > > git-master might be used. I also included a reference to
> > > Git#Branches for the curious.
> > >
> > > Chris, does that work for you? I hope so!
> > >
> > > …Now on to the next areas…
> > >
> > > David
> > >
> > > P.S. Chris, you don’t need to apologize to me for being
> > > argumentative; I can be obnoxiously argumentative as well—for which
> > > I apologize as well.>
> > > > On Jan 27, 2017, at 2:06 PM, Geert Janssens
> > >
> > > <geert.gnucash at kobaltwit.be> wrote:
> > > > Op vrijdag 27 januari 2017 11:09:10 CET schreef Chris Good & David T:
> > > >> On another point, you commented on the page that I took away
> > > >> information about committing to master. A few things on this:
> > > >> First, for documentation, a non commit contributor is only going
> > > >> to be documenting existing features, so they will ALWAYS be using
> maint.
> > > >> One of the wiki pages for git states this; I was merely making
> > > >> this agree
> > >
> > > with that.
> > >
> > > >> Second, the pages on git already go into this in more detail
> > > >> (which, by the way, was why I suggested having one git wiki page
> > > >> earlier), so adding it here only muddies the water. Third, you
> > > >> did precisely this with regard to the user of xmllint/xsltproc
> > > >> and make. David
> > > >>
> > > >> Non commit  contributors are not the only ones to use this page.
> > > >>
> > > >> Both Git and Git_For_Newbies say:
> > > >>  maint
> > > >>
> > > >>    Bugfixes, translations, improvements of the documentation
> > > >> should
> > > >>
> > > >> *usually* be applied on this branch.
> > > >
> > > > For sake of the discussion I will add the exact rule would be that
> > > > you should document a feature on the same branch as it is
> > > > available on in the gnucash repository, with maint taking priority
> > > > over master if it's
> > >
> > > available on both.
> > >
> > > > It's true that currently most new documentation is written for
> > > > features that have already been released in a stable gnucash
> > > > version (and hence are on the maint branch), so this documentation
> > > > should go on
> > >
> > > the maint branch as well.
> > >
> > > > However this is partly because the documentation is running behind
> > > > so much and the current writers are still catching up (for which
> > > > I'm immensely grateful!)
> > > >
> > > > There is a period in each development cycle where this is not so
> > > > obvious. When we start releasing development snaphots - the next
> > > > one being 2.7.0 somewhere later this year - documenters are
> > > > invited to look at the new features that weren't previously
> > > > released and write documentation for those. Similar to how
> > > > translators mostly work on the maint branch, except during the
> > > > prerelease period. Both are examples of
> > >
> > > when to create patches against the master branch.
> > >
> > > > If you find a way to express this distinction concisely and
> > > > clearly, I'd love to have this at least mentioned in some way indeed.
> > > >
> > > > Geert
> >
> > Hi David,
> >
> > Much better thanks!
> > I have made a couple of slight adjustments.
> >
> > 1.  Changing
> > for example, when GnuCash is in a development cycle), To for example,
> > a feature only in a future stable release),
> >
> > because GnuCash is effectively always in a development cycle.
> >
> > 2. Changing
> > For more on this, see [[Git#Branches|Git - Branches]] To See
> > [[Git#Branches|Git - Branches]] for more on this.
> >
> > I have previously been called to task for not ending a sentence with a
> > full stop. When other points at the same list level all end in a full
> > stop, I think we should be consistent. You may have been concerned,
> > like I was, that the full stop would cause problems with the link. I
> > now try to restructure the sentence so the link is not at the end of the
> sentence.
> >
> The full stop will not interfere with the link if it remains outside of the square
> brackets.
> 
> And it probably even wouldn't if it was part of the description section inside
> the brackets.
> 
> But your alternative sentence is perfectly fine as well :)
> 
> Geert

Hi Geert,

Oops, I just found this again. I meant to reply long ago.
I have seen this problem where a browser, I don't know which now, incorrectly copied the link with the full stop, even though it clearly should not have.
It has probably been fixed long ago and I should forget about it.

Regards, Chris Good
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4817 bytes
Desc: not available
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20170207/160c9875/attachment.p7s>