Re: private-kvp merge reverted other changes since November.
On Monday 12 May 2014 14:47:13 John Ralls wrote: On May 8, 2014, at 1:40 PM, Geert Janssens janssens-ge...@telenet.be wrote: You're welcome. I was too curious to let it pass and it was a good opportunity to learn something about git merge in the process. The only actual damage seems to have been in src/report/report-gnome/gnc-plugin-page-report.c; at least that is the only file with significant diffs in `git diff 9d40512..49a5909`, which shows the net change from your reverting the merge, remerging, and re-doing the C++ fixups. All of the changes from this year were reversed in the original merge commit, so I must have messed up when handling the last or next-to-last back-merge and blithely picked the branch version for every diff. git rerere remembered and did the same when I did the forward-merge. That's a reasonable explanation. So I’m going to revise my earlier worry about git being able to safely merge a long running commit: I’m not sure *I* can safely merge a long-running and complex branch in the face of dozens of conflicts. I guess that’s an argument for merging frequently to keep the conflicts under control. Agreed. Your kvp branch was from before the git era when it wasn't possible to merge. We can now revise our strategy and merge master more frequently in longer running topic branches to reduce the merge complexity. It will be a matter of finding a good balance. It doesn't make sense either to merge after each and every commit. That does indeed clutter up the branch history and makes the history harder to read in tools such as gitk. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash at Open Help?
On Friday 09 May 2014 18:18:57 Wm Tarr wrote: On 07/05/2014 22:56, John Ralls wrote: On May 7, 2014, at 1:14 PM, Ekaterina Gerasimova kittykat3...@gmail.com wrote: Hi, I'm not sure if you're the right person to talk to about user help in GnuCash (documentation, mailing lists and other forms), so I would appreciate it if you could point me in the right direction if you're not the right person. I'm a long term GnuCash user and the current GNOME documentation team lead, so I'm somewhat interested in how GnuCash manage their documentation and user help. For the last few years, the GNOME docs team have been attending Open Help[1], and annual conference which is dedicated to documentation and user help in the open source/Free software world. The conference usually has many projects attending, such as Wikimedia and Debian, so makes a really good forum for documentation related talk and brainstorming. I've managed to wrangle a few free passes for the conference, so I was wondering if GnuCash would be interested in coming this year? There are still presentation/panel slots available if you're interested in talking about the project, and there are normally hackfest spaces available for a few days after the conference too. Looking forward to hearing from you Kat [1] http://openhelpconference.com/ Kat, Thanks for thinking of us. I'm forwarding this to our developer's list to bring it to the attention of the rest of the team. It's a standard mailman list with a low level of traffic, but I'll understand completely if you choose not to subscribe to carry on the discussion. I'll relay your replies if you like. I'm not much of a documenter and any not able to attend a conference in mid-June. Perhaps someone else will pipe up. As for how we handle it, we maintain a separate repository for it; the public mirror is at https://github.com/Gnucash/gnucash-docs. We're currently releasing a new set in sync with GnuCash releases even if there are no documentation changes since the previous release. Online and downloadable versions of the released docs are, as you probably know, at http://www.gnucash.org/docs.phtml. The docs themselves are in DocBook as is standard for Gnome. We've had several instances of potential contributors being scared off because there are no good and Free direct editors and XML is a bit intimidating. We've discussed a few alternatives but haven't been able to agree on any. Any progress on this from a thought POV? There are currently no changes planned in the documentation infrastructure. I managed to get some of it working and some of it written up but then thought ... why bother if no-one else will go through the hoops? Why bother ? Because users will certainly be grateful for improvements in the documentation :) The conference is an ocean away from me. That's the same for me. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash at Open Help?
On 7 May 2014 22:56, John Ralls jra...@ceridwen.us wrote: On May 7, 2014, at 1:14 PM, Ekaterina Gerasimova kittykat3...@gmail.com wrote: Hi, I'm not sure if you're the right person to talk to about user help in GnuCash (documentation, mailing lists and other forms), so I would appreciate it if you could point me in the right direction if you're not the right person. I'm a long term GnuCash user and the current GNOME documentation team lead, so I'm somewhat interested in how GnuCash manage their documentation and user help. For the last few years, the GNOME docs team have been attending Open Help[1], and annual conference which is dedicated to documentation and user help in the open source/Free software world. The conference usually has many projects attending, such as Wikimedia and Debian, so makes a really good forum for documentation related talk and brainstorming. I've managed to wrangle a few free passes for the conference, so I was wondering if GnuCash would be interested in coming this year? There are still presentation/panel slots available if you're interested in talking about the project, and there are normally hackfest spaces available for a few days after the conference too. Looking forward to hearing from you Kat [1] http://openhelpconference.com/ Kat, Thanks for thinking of us. I'm forwarding this to our developer's list to bring it to the attention of the rest of the team. It's a standard mailman list with a low level of traffic, but I'll understand completely if you choose not to subscribe to carry on the discussion. I'll relay your replies if you like. No problem, I've subscribed now. I'm not much of a documenter and any not able to attend a conference in mid-June. Perhaps someone else will pipe up. Thanks for passing it on! As for how we handle it, we maintain a separate repository for it; the public mirror is at https://github.com/Gnucash/gnucash-docs. We're currently releasing a new set in sync with GnuCash releases even if there are no documentation changes since the previous release. Online and downloadable versions of the released docs are, as you probably know, at http://www.gnucash.org/docs.phtml. The docs themselves are in DocBook as is standard for Gnome. We've had several instances of potential contributors being scared off because there are no good and Free direct editors and XML is a bit intimidating. We've discussed a few alternatives but haven't been able to agree on any. Interesting… GNOME has actually been actively moving from DocBook to Mallard[1] since around 2010-2011. Mallard is also XML, but it was created to be the ideal tool for task-oriented user help for software. It was created by Shaun McCance, who was the GNOME docs team lead at the time. There were a number of reasons for the switch. It was partially done as part of an effort to rewrite GNOME documentation under a CC-by-SA 3.0 license rather than the GFDL. The docs team thought that the benefits to changing the license, namely being able to exchange information relatively feely with Wikipedia (and other resources) while reducing the licensing burden for reusing the docs elsewhere, outweighed the workload. As you can imagine, relicensing is a difficult and complex process, so with the UI changes taking place around the GNOME 3 release, it was a perfect opportunity for the docs team to write the help from scratch as updates would have pretty much amounted to the same thing. Regards, John Ralls [1] http://projectmallard.org/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
On May 13, 2014, at 3:53 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Monday 12 May 2014 14:47:13 John Ralls wrote: On May 8, 2014, at 1:40 PM, Geert Janssens janssens-ge...@telenet.be wrote: You're welcome. I was too curious to let it pass and it was a good opportunity to learn something about git merge in the process. The only actual damage seems to have been in src/report/report-gnome/gnc-plugin-page-report.c; at least that is the only file with significant diffs in `git diff 9d40512..49a5909`, which shows the net change from your reverting the merge, remerging, and re-doing the C++ fixups. All of the changes from this year were reversed in the original merge commit, so I must have messed up when handling the last or next-to-last back-merge and blithely picked the branch version for every diff. git rerere remembered and did the same when I did the forward-merge. That's a reasonable explanation. So I’m going to revise my earlier worry about git being able to safely merge a long running commit: I’m not sure *I* can safely merge a long-running and complex branch in the face of dozens of conflicts. I guess that’s an argument for merging frequently to keep the conflicts under control. Agreed. Your kvp branch was from before the git era when it wasn't possible to merge. We can now revise our strategy and merge master more frequently in longer running topic branches to reduce the merge complexity. It will be a matter of finding a good balance. It doesn't make sense either to merge after each and every commit. That does indeed clutter up the branch history and makes the history harder to read in tools such as gitk. Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development on both branches risks replaying what was the right answer with last week's code but isn't with this week's, so if there are conflicts resolved in the merge it stays so that new code builds on the resolved result rather than continuing to diverge. I think merges into master should happen for every module (e.g. gncguid, gncdate) so that conflicts coming into master are limited to a single subject. That should make it a bit easier for the person doing the merge to keep track of which way to resolve the conflicts. That will still produce a ladder appearance in gitk and friends. I don't find that objectionable, but apparently some people do. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
On May 13, 2014, at 11:47 AM, John Ralls jra...@ceridwen.us wrote: Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development on both branches risks replaying what was the right answer with last week's code but isn't with this week's, so if there are conflicts resolved in the merge it stays so that new code builds on the resolved result rather than continuing to diverge. I think merges into master should happen for every module (e.g. gncguid, gncdate) so that conflicts coming into master are limited to a single subject. That should make it a bit easier for the person doing the merge to keep track of which way to resolve the conflicts. That will still produce a ladder appearance in gitk and friends. I don't find that objectionable, but apparently some people do. I agree that merging master into topic branches frequently is a good idea. I have a long running branch where I do all my real work and merge master into it often. This seems to work well. I've also created more short lived topic branches and used them like this. In the other direction, I think that once a topic branch is merged to master it should be abandoned (unless it is used to fix bugs in the stuff that was just merged). A new topic branch should be created for subsequent changes, even if they are related to the changes that were just merged (such as the same changes to a different part of the code). I'm not sure if this is what you're suggesting or not, but it would seem to avoid a ladder appearance (if I know what you mean by that). Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
On May 13, 2014, at 10:39 AM, Mike Alexander m...@umich.edu wrote: On May 13, 2014, at 11:47 AM, John Ralls jra...@ceridwen.us wrote: Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development on both branches risks replaying what was the right answer with last week's code but isn't with this week's, so if there are conflicts resolved in the merge it stays so that new code builds on the resolved result rather than continuing to diverge. I think merges into master should happen for every module (e.g. gncguid, gncdate) so that conflicts coming into master are limited to a single subject. That should make it a bit easier for the person doing the merge to keep track of which way to resolve the conflicts. That will still produce a ladder appearance in gitk and friends. I don't find that objectionable, but apparently some people do. I agree that merging master into topic branches frequently is a good idea. I have a long running branch where I do all my real work and merge master into it often. This seems to work well. I've also created more short lived topic branches and used them like this. In the other direction, I think that once a topic branch is merged to master it should be abandoned (unless it is used to fix bugs in the stuff that was just merged). A new topic branch should be created for subsequent changes, even if they are related to the changes that were just merged (such as the same changes to a different part of the code). I'm not sure if this is what you're suggesting or not, but it would seem to avoid a ladder appearance (if I know what you mean by that). It’s not. I see no reason to abandon a branch just because it’s merged into master, and if you really have a long-running branch where you do all of your work, neither do you. It won’t avoid the ladder look, either. There will just be a bunch of shortish branches instead of one long one. The matter of abandoned branches reminds me that I haven’t yet cleared out all of the old branches that I merged into ‘archive’. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
On 13 May 2014 18:39, Mike Alexander m...@umich.edu wrote: ... In the other direction, I think that once a topic branch is merged to master it should be abandoned (unless it is used to fix bugs in the stuff that was just merged). A new topic branch should be created for subsequent changes, even if they are related to the changes that were just merged (such as the same changes to a different part of the code). I'm not sure if this is what you're suggesting or not, but it would seem to avoid a ladder appearance (if I know what you mean by that). Working with git in the past I have considered that topic branches should be as short lived as possible. A piece of work should be broken into a number of self contained chunks and each one done on a branch, merged back to trunk, and left. The next chunk being started on a new branch. Of course this is not always possible as sometimes major changes are required which must all be done before the s/w reaches a new consistent state. In that case merging will always be tricky. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
On 13 May 2014 21:09, John Ralls jra...@ceridwen.us wrote: On May 13, 2014, at 10:39 AM, Mike Alexander m...@umich.edu wrote: On May 13, 2014, at 11:47 AM, John Ralls jra...@ceridwen.us wrote: Yeah, it would be silly to merge after every commit. One strategy might be to frequently merge from master and then revert the merge if there are no conflicts. ISTM that relying on rerere in the face of ongoing development on both branches risks replaying what was the right answer with last week's code but isn't with this week's, so if there are conflicts resolved in the merge it stays so that new code builds on the resolved result rather than continuing to diverge. I think merges into master should happen for every module (e.g. gncguid, gncdate) so that conflicts coming into master are limited to a single subject. That should make it a bit easier for the person doing the merge to keep track of which way to resolve the conflicts. That will still produce a ladder appearance in gitk and friends. I don't find that objectionable, but apparently some people do. I agree that merging master into topic branches frequently is a good idea. I have a long running branch where I do all my real work and merge master into it often. This seems to work well. I've also created more short lived topic branches and used them like this. In the other direction, I think that once a topic branch is merged to master it should be abandoned (unless it is used to fix bugs in the stuff that was just merged). A new topic branch should be created for subsequent changes, even if they are related to the changes that were just merged (such as the same changes to a different part of the code). I'm not sure if this is what you're suggesting or not, but it would seem to avoid a ladder appearance (if I know what you mean by that). It’s not. I see no reason to abandon a branch just because it’s merged into master, and if you really have a long-running branch where you do all of your work, neither do you. It won’t avoid the ladder look, either. There will just be a bunch of shortish branches instead of one long one. If you want to work in that way I suggest having a look at git rebase. Rather than merging the branch into master this effectively moves the base of the branch along to the current master and makes the tree look much simpler. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch, enable-python and some install-impl.sh vs custom.sh suggestions
On 10/05/2014 10:36, Geert Janssens wrote:
On Friday 09 May 2014 16:51:06 Wm Tarr wrote:
I'm working my way through getting python enabled with Windows from
scratch.
Great ! Will you document your success ?
When it happens, definitely. Made a lot of progress today, I can do an
error free build with enable-python. There is a lot of hackery to make
sense of but these two issues came up that I'd like someone else to look at
1. there is a conflict between gcdev\gnucash\build\config.h and
Python27\include\pyconfig.h
config.h expects pyconfig.h to have the line
#define HAVE_PUTENV 1
rather than
#define HAVE_PUTENV
I hacked pyconfig.h to include the 1 on a life's too short and I'm
hacking principle.
Depending on what it is in other python's on other OSs it seems to me
this is easy enough to get around, it is merely a matter of doing it the
best way, i.e. adjust Python, adjust gnc or ignore the warning in the build.
2. More seriously (and I think recently introduced) is a duplicate
variable (I didn't make a note of the error msg) between
\gcdev\gnucash.git\src\engine\Transaction.c
and
\gcdev\gnucash.git\src\engine\test\utest-Transaction.c
I'm guessing this isn't specific to enable-python so much as the extra
tests being run for the first time by anyone in the last week or so.
my hack was to change utest-Transaction.c
const char *trans_is_closing_str = book_closing;
to
static const char *trans_is_closing_str = book_closing;
which seemed to fix it. I'll leave people closer to that bit of the
code to decide what is best.
More generally the
checking for /c/Python27/python script directory...
${prefix}\Lib\site-packages
checking for /c/Python27/python extension module directory...
${exec_prefix}\Lib\site-packages
just aren't working out on Win.
I'll see how I feel tomorrow but the way I'm looking at it right now I
think I'm going to sed the Makefile after configure in function
inst_gnucash() because the results *really* are that ugly and MSYS
(unlike cygwin) can't seem to sanitise the paths reliably and I've spent
much too long on this unimportant issue.
It is late. Apart from 1. and 2. it looks like tidying up is the next step.
It is late so I'll reply to the rest of the posting another day.
--
Wm
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
--On May 13, 2014 9:17:58 PM +0100 Colin Law clan...@gmail.com wrote: It’s not. I see no reason to abandon a branch just because it’s merged into master, and if you really have a long-running branch where you do all of your work, neither do you. It won’t avoid the ladder look, either. There will just be a bunch of shortish branches instead of one long one. If you want to work in that way I suggest having a look at git rebase. Rather than merging the branch into master this effectively moves the base of the branch along to the current master and makes the tree look much simpler. That's what I do. I rebase my branches onto master each time it is updated. This seems to work well and keeps the tree much simpler. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
On May 13, 2014, at 9:01 PM, Mike Alexander m...@umich.edu wrote: --On May 13, 2014 9:17:58 PM +0100 Colin Law clan...@gmail.com wrote: It’s not. I see no reason to abandon a branch just because it’s merged into master, and if you really have a long-running branch where you do all of your work, neither do you. It won’t avoid the ladder look, either. There will just be a bunch of shortish branches instead of one long one. If you want to work in that way I suggest having a look at git rebase. Rather than merging the branch into master this effectively moves the base of the branch along to the current master and makes the tree look much simpler. That's what I do. I rebase my branches onto master each time it is updated. This seems to work well and keeps the tree much simpler. That's the SVN way. We discussed this back in March [1] and decided that we're not going to do that anymore. If you want to revisit that you need a better argument than that's the way I've always done it, considering that the Git community at large doesn't seem to consider it a best practice. Regards, John Ralls [1] http://lists.gnucash.org/pipermail/gnucash-devel/2014-March/037289.html ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: private-kvp merge reverted other changes since November.
--On May 13, 2014 9:35:58 PM -0700 John Ralls jra...@ceridwen.us wrote: That's the SVN way. We discussed this back in March [1] and decided that we're not going to do that anymore. If you want to revisit that you need a better argument than that's the way I've always done it, considering that the Git community at large doesn't seem to consider it a best practice. So what has been wrong with my commits that you would like me to fix? Do you think absolutely everything should go on a branch and get merged into master or maint? Or is it ok to put small changes directly on master or maint? Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
