> -----Original Message----- > From: Geert Janssens [mailto:geert.gnuc...@kobaltwit.be] > Sent: Saturday, 28 January 2017 8:05 PM > To: Chris Good <chris.g...@ozemail.com.au> > Cc: 'David T.' <sunfis...@yahoo.com>; gnucash-devel@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:sunfis...@yahoo.com] > > > Sent: Friday, 27 January 2017 9:04 PM > > > To: Geert Janssens <geert.gnuc...@kobaltwit.be> > > > Cc: gnucash-devel@gnucash.org; Chris Good > > > <chris.g...@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.gnuc...@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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
