Re: [GNC-dev] [Gnucash/gnucash-docs] Adding reconciliation to glossary (#110)

2018-08-24 Thread John Ralls


> On Aug 24, 2018, at 10:18 AM, David T. via gnucash-devel 
>  wrote:
> 
> Thanks for the hand-holding…
> 
> Round 3. It looks like this one is on the right branch…
> 
> Now, as for whether this process is easier than the older way, I am not 
> entirely convinced. The elimination of the extra layer of maintaining the 
> local repository and development platform is likely to make the web-edit 
> process more generally accessible, however.
> 
> There still remains the issue of needing to muck around with DocBook XML 
> tagging, but as I have said before, that hasn’t my main barrier to 
> contribution. It would be nice if a writer could do their edits in a word 
> processor of choice and then pump out valid DocBook markup for inclusion in 
> the docs.

That would be nice indeed, but the only such solution that I’m aware of is an 
old plugin for LibreOffice and it doesn’t work very well; as I said earlier the 
pandoc pre- and post-processing approach doesn’t round-trip very well either.

We could, I suppose, switch to docx format for the document source and use 
either pandoc or a custom xslt stylesheet to convert that to DocBook, but I 
worry that different word processors or even different versions of the same 
word processor might make a bunch of extraneous changes to the document that 
are invisible in the word processor display but would make for ugly change sets.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [Gnucash/gnucash-docs] Adding reconciliation to glossary (#110)

2018-08-24 Thread David T. via gnucash-devel
Thanks for the hand-holding…

Round 3. It looks like this one is on the right branch…

Now, as for whether this process is easier than the older way, I am not 
entirely convinced. The elimination of the extra layer of maintaining the local 
repository and development platform is likely to make the web-edit process more 
generally accessible, however.

There still remains the issue of needing to muck around with DocBook XML 
tagging, but as I have said before, that hasn’t my main barrier to 
contribution. It would be nice if a writer could do their edits in a word 
processor of choice and then pump out valid DocBook markup for inclusion in the 
docs.

David

> On Aug 24, 2018, at 12:52 PM, Geert Janssens  
> wrote:
> 
> Op vrijdag 24 augustus 2018 18:13:46 CEST schreef David T.:
>> Geert,
>> 
>> I went ahead and closed the PR.
>> 
>> First problem: once I closed the PR, I could not locate the changes I made;
>> there doesn’t appear to be a way to locate those changes. Did Github delete
>> them altogether? Oh, wait. I see the changes in the Closed PR section,
>> although I don’t know how I leverage that.
>> 
> The changes are still in your own fork. I suppose you were still looking in 
> the Gnucash/gnucash-docs repository instead of sunfish62/gnucash-docs as you 
> did see the closed PR.
> 
> If you go to your own fork under the code tab, here is the dropdown box named 
> "Branch" with the name of the currently selected branch. If you click on it 
> you will also find your "Bug-791169---Add-reconciliation-definition". If you 
> click on that one, your original commit will re-appear.
> 
>> In this case, the change was pretty simple, so I just recreated it from
>> scratch (I probably would be much crankier if the changes were more
>> substantial!). I went to my fork, (re) added my changes, clicked the Commit
>> and create PR option. I named the branch bug-791169 and gave the commit the
>> name “Bug 791169 - Adding Reconciliation definition to Glossary” [BTW,
>> github tells me that making my commit name longer than 50 characters shows
>> me to be the amateur I am].
> 
> Huh, that makes me an amateur equally, because I don't check the length of 
> the 
> name either when committing changes directly from the command line :)
> Git doesn't complain about that, only github does...
> 
>> 
>> Now, I have a PR against my own fork. I would rather issue the PR against
>> Gnucash/gnucash-docs, but don’t see how to get there.
>> 
> I suppose this is because you selected the wrong base fork while generating 
> the pull request. The names are a bit confusing I admit. But the direction of 
> the arrow between the forks should give a clue:
> you want changes from the repository on the right to be included in the 
> repository on the left (no doubt this interface was made by someone whose 
> natural language reads from right to left...).
> 
> So you can
> 1. close the PR against your own repo
> 2. ensure you're in your own repo
> 3. select the branch with your commit (that should now be "bug-791169") 
> 4. start a PR. This time make sure the left-hand side fork is Gnucash/gnucash-
> docs, with branch maint and the right-hand side fork is your repo and branch.
> 
>> Kinks in the hose!
>> 
> We're working on ironing them out.
> 
> Geert
> 
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: [GNC-dev] [Gnucash/gnucash-docs] Adding reconciliation to glossary (#110)

2018-08-24 Thread David T. via gnucash-devel
Geert,

I went ahead and closed the PR. 

First problem: once I closed the PR, I could not locate the changes I made; 
there doesn’t appear to be a way to locate those changes. Did Github delete 
them altogether? Oh, wait. I see the changes in the Closed PR section, although 
I don’t know how I leverage that.

In this case, the change was pretty simple, so I just recreated it from scratch 
(I probably would be much crankier if the changes were more substantial!). I 
went to my fork, (re) added my changes, clicked the Commit and create PR 
option. I named the branch bug-791169 and gave the commit the name “Bug 791169 
- Adding Reconciliation definition to Glossary” [BTW, github tells me that 
making my commit name longer than 50 characters shows me to be the amateur I 
am].

Now, I have a PR against my own fork. I would rather issue the PR against 
Gnucash/gnucash-docs, but don’t see how to get there.

Kinks in the hose!

David

> On Aug 24, 2018, at 11:08 AM, Geert Janssens  > wrote:
> 
> Thanks David to run the experiment of working directly on github.
> 
> That allows me to write my review there as well :)
> 
> I have two remarks:
> 
> We generally ask "commits" to reference the bug they fix if there is one. I 
> see you have chosen to reference the bug in your branch name instead. The 
> best way to do this is to use the bug and bug title as commit title (the 
> first field in the "Commit changes" frame on the edit page).
> Any further clarifications or comments can be added in the second field.
> Your PR is crossing branches. That is, you created your commit starting from 
> the maint branch (good, as this change is useful for gnucash 3.x and up) and 
> then created a PR against master. That should be avoided.
> So even though the github interface is cleaner a minimal understanding of git 
> branches is still needed when unsing the integrated editor. This is in no way 
> meant to comment on your effort. Rather I'm using your experiment to draw 
> conclusions and discover pitfalls.
> 
> Do you want to continue the experiment and see if you can correct this ?
> I don't think you can change the commit message unless you redo the commit. 
> You don't have to, I'll do so when pulling your PR.
> However you can test how hard you feel it is to fix the PR to be against the 
> proper branch. If you want to, the way to do so is to close this PR, go back 
> to your "Bug-791169---Add-Reconciliation-definition" branch and create a new 
> PR, this time against the maint branch.
> 
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub 
> , or 
> mute the thread 
> .
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel