GnuCash page Documentation Update Instructions has been changed by Sunfish62

Geert Janssens geert.gnucash at kobaltwit.be
Sat Jan 28 04:05:29 EST 2017


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


More information about the gnucash-devel mailing list