Re: Branching strategy for git
On Wednesday 26 March 2014 12:53:36 Derek Atkins wrote: John Ralls jra...@ceridwen.us writes: It will be. When we’re ready to release 2.8, the ‘maint’ branch will be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new ‘maint’ branch from ‘master’. We could even do that at 2.8.0, because merging ‘maint’ into ‘master’ isn’t a big deal until ‘master’ diverges. Waiting is a hold-over from SVN, which until 1.7 didn’t allow that. Why not call it ‘2.6’ right away? Just to make maintaining the wiki easier: If ‘maint’ is always the current bug-fix branch, then the policy can say that and not have to be changed every 3 years. I guess I didn't realize (or contemplate) we could easily rename the branch later -- but I suppose that makes sense based on the way that git handles branches. 'Renaming' is a fairly glossy term for what will happen exactly. I'm mostly just thinking about way way way down the road someone wanting to come back and see the work done on e.g. the 2.6 maint branch, when maint isn't 2.6 anymore. At that point there will be a 2.6 branch that took over from maint right before maint was aligned with 2.8. In simplified ascii art - Right before the first 2.8 release: A - B - C - E -(master) \ / D - -(maint) Note here that all of the changes on the maint branch get merged into master. This follows from the premise that bugfixes are done on the oldest branch that needs them and merged upwards into master (or more recent stable branches if there are any). Releasing 2.8 would simply mean tagging commit E with the 2.8.0 release tag. I won't add it here as it's difficult to represent in ascii. But after that the following branch structure will be set up: A - B - C - E -(master, maint) \ / D - -(maint-2.6) And further development happens from there. Bugfixes that still have to be applied to 2.6 will be done on the maint-2.6 branch and merged upwards again into maint and master, bugfixes that should go into 2.8 will be done on maint and merged upwards into master, new development goes on master only. Keeping a branch head for old maintenance branches is important for another reason. Suppose the maint-2.6 branch name is not pushed into the main repository we would get a commit log like this: A - B - C - E -(master, maint) \ / D But as branches are equal in git this could just as well be written as A - D - C - E -(master, maint) \ / B (I swapped D and B in case you're wondering). And suddenly it looks as if commit D has always been part of master and commit B may have been the bugfix. So without the branch name it's impossible to determine what was what in history. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Tuesday 25 March 2014 09:17:29 John Ralls wrote: On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Have you experimented at all with what the upstream looks like if you merge a private branch instead of rebasing it and then push the result? I *think* the private branch's objects will get pushed upstream, but the ref/heads entry won't, but I don't know that for sure. If I'm right, then the other change in the wiki will be to remove all of the stuff about rebasing instead of merging. Do you mean there should be no reference to rebasing anymore and to promote merging for everthing ? I think it still makes sense to rebase local branches right before making them public (which can be either by pushing to a public repository for those that have commit access or by creating a pull request). This somewhat limits the number of multi-parent commits in the public repository. Lots of those tend to make history harder to read or represent. On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? How much overlap is there in the 'boost' and 'mvc' work ? I'm just trying to estimate if they can be done on separate branches. But perhaps you already have a vision on that. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Saturday 22 March 2014 18:39:13 John Ralls wrote: On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be wrote: I like the workflow as proposed in the git workflows man page (section Branch management for a release and following). They propose a long-term maintenance branch. Only when a new feature release is done, a separate maintenance branch for the previous stable series is created. So when 2.8.0 gets tagged, the current head of stable is branched off into stable-2.6. Then stable is fast forwarded to the 2.8.0 release tag. It won’t quite fast-forward because of ChangeLog and NEWS, but those are minor issues; the releaser can just resolve to the new version. Zooming in on this issue: If I understand the release process well NEWS is hand-written (based on a preformatted log since previous release) and Changelog is autogenerated from the git log. Looking at both files I see that NEWS groups changes per version while Changelog just lists changes by date. Let's assume we're in the current situation: 2.8.0 has been released and there are a couple of bug fixes that will appear in both 2.6.x and 2.8.1. What should come in the NEWS file ? For the 2.6.x release there should be a section listing the changes in 2.6.x. For the 2.8.1 release I would expect both a section for 2.6.x (assuming this gets released right before 2.8.1) and one for 2.8.1. I'll note that this didn't happen for 2.4.x and 2.6. From the first 2.5.x release the NEWS file on trunk wasn't updated with 2.4.x releases anymore. That looks like a flaw in our release infrastructure that didn't get noticed because of the weak merging capabilities of svn. With git this can be handled better because if we merge the 2.6.x release changes upwards that would bring in the 2.6.x release section. It may cause a merge conflict but at least we're informed there is a new section to add. I'm not even sure this would create a merge conflict because the existing news sections don't change. Only a new one gets added. The only way to be sure is to test. Changelog may be more difficult though we'll have to run a test to be sure. The main question for me here is whether or not our code to generate the Changelog file can properly handle multi-parent commits ? This is important to generate log entries for the changes from upwards merged bugfixes into master. If it does, then merge conflicts when merging maint into master can always be resolved in favour of the Changelog file on master. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 27, 2014, at 2:13 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Saturday 22 March 2014 18:39:13 John Ralls wrote: On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be wrote: I like the workflow as proposed in the git workflows man page (section Branch management for a release and following). They propose a long-term maintenance branch. Only when a new feature release is done, a separate maintenance branch for the previous stable series is created. So when 2.8.0 gets tagged, the current head of stable is branched off into stable-2.6. Then stable is fast forwarded to the 2.8.0 release tag. It won’t quite fast-forward because of ChangeLog and NEWS, but those are minor issues; the releaser can just resolve to the new version. Zooming in on this issue: If I understand the release process well NEWS is hand-written (based on a preformatted log since previous release) and Changelog is autogenerated from the git log. Looking at both files I see that NEWS groups changes per version while Changelog just lists changes by date. Let's assume we're in the current situation: 2.8.0 has been released and there are a couple of bug fixes that will appear in both 2.6.x and 2.8.1. What should come in the NEWS file ? For the 2.6.x release there should be a section listing the changes in 2.6.x. For the 2.8.1 release I would expect both a section for 2.6.x (assuming this gets released right before 2.8.1) and one for 2.8.1. I'll note that this didn't happen for 2.4.x and 2.6. From the first 2.5.x release the NEWS file on trunk wasn't updated with 2.4.x releases anymore. That looks like a flaw in our release infrastructure that didn't get noticed because of the weak merging capabilities of svn. With git this can be handled better because if we merge the 2.6.x release changes upwards that would bring in the 2.6.x release section. It may cause a merge conflict but at least we're informed there is a new section to add. I'm not even sure this would create a merge conflict because the existing news sections don't change. Only a new one gets added. The only way to be sure is to test. Changelog may be more difficult though we'll have to run a test to be sure. The main question for me here is whether or not our code to generate the Changelog file can properly handle multi-parent commits ? This is important to generate log entries for the changes from upwards merged bugfixes into master. If it does, then merge conflicts when merging maint into master can always be resolved in favour of the Changelog file on master. I'm actually in favor of deleting both because I don't think that anyone ever looks at them. I expect that everyone gets the News information from the website or email if they even bother to read past the subject line, and uses the history from git log, their git GUI, or on Github to see what was committed and when. That said, if we do continue them, then I agree that resolving NEWS won't be that hard. The worst case will be if there's been an unstable release between two stable releases, and one need only remove the === lines and add the file. I don't think ChangeLog is a big deal either: The automated generation will reflect all of the changes since the previous release on that branch, including the ones merged in from 'maint', so one can just resolve in favor of the new version and be done with it. It would be worthwhile to play around with the merge styles a bit to see which one produces the fewest conflicts. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 27, 2014, at 1:47 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Tuesday 25 March 2014 09:17:29 John Ralls wrote: On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Have you experimented at all with what the upstream looks like if you merge a private branch instead of rebasing it and then push the result? I *think* the private branch's objects will get pushed upstream, but the ref/heads entry won't, but I don't know that for sure. If I'm right, then the other change in the wiki will be to remove all of the stuff about rebasing instead of merging. Do you mean there should be no reference to rebasing anymore and to promote merging for everthing ? I think it still makes sense to rebase local branches right before making them public (which can be either by pushing to a public repository for those that have commit access or by creating a pull request). This somewhat limits the number of multi-parent commits in the public repository. Lots of those tend to make history harder to read or represent. OK. On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? How much overlap is there in the 'boost' and 'mvc' work ? I'm just trying to estimate if they can be done on separate branches. But perhaps you already have a vision on that. The Boost changes will touch everything because it's going to include a lot of API shrinkage, like getting rid of most of the different ways we say time, and changing object calling conventions from gnc_footype_bar(foo, baz) to foo-bar(baz). MVC is more of a refactoring exercise, pulling everything that doesn't immediately draw on the screen or get from the user out of the GUI code into a controller layer, the objective being to make switching UIs a more-or-less mechanical exercise. They'll need to be frequently merged back-and-forth with master to keep everything in sync. Do you think that will add too much extra work and that we should just do everything in master as we have been? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Thursday 27 March 2014 07:25:20 John Ralls wrote: On Mar 27, 2014, at 2:13 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Saturday 22 March 2014 18:39:13 John Ralls wrote: On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be wrote: I like the workflow as proposed in the git workflows man page (section Branch management for a release and following). They propose a long-term maintenance branch. Only when a new feature release is done, a separate maintenance branch for the previous stable series is created. So when 2.8.0 gets tagged, the current head of stable is branched off into stable-2.6. Then stable is fast forwarded to the 2.8.0 release tag. It won’t quite fast-forward because of ChangeLog and NEWS, but those are minor issues; the releaser can just resolve to the new version. Zooming in on this issue: If I understand the release process well NEWS is hand-written (based on a preformatted log since previous release) and Changelog is autogenerated from the git log. Looking at both files I see that NEWS groups changes per version while Changelog just lists changes by date. Let's assume we're in the current situation: 2.8.0 has been released and there are a couple of bug fixes that will appear in both 2.6.x and 2.8.1. What should come in the NEWS file ? For the 2.6.x release there should be a section listing the changes in 2.6.x. For the 2.8.1 release I would expect both a section for 2.6.x (assuming this gets released right before 2.8.1) and one for 2.8.1. I'll note that this didn't happen for 2.4.x and 2.6. From the first 2.5.x release the NEWS file on trunk wasn't updated with 2.4.x releases anymore. That looks like a flaw in our release infrastructure that didn't get noticed because of the weak merging capabilities of svn. With git this can be handled better because if we merge the 2.6.x release changes upwards that would bring in the 2.6.x release section. It may cause a merge conflict but at least we're informed there is a new section to add. I'm not even sure this would create a merge conflict because the existing news sections don't change. Only a new one gets added. The only way to be sure is to test. Changelog may be more difficult though we'll have to run a test to be sure. The main question for me here is whether or not our code to generate the Changelog file can properly handle multi-parent commits ? This is important to generate log entries for the changes from upwards merged bugfixes into master. If it does, then merge conflicts when merging maint into master can always be resolved in favour of the Changelog file on master. I'm actually in favor of deleting both because I don't think that anyone ever looks at them. I expect that everyone gets the News information from the website or email if they even bother to read past the subject line, and uses the history from git log, their git GUI, or on Github to see what was committed and when. I don't have a strong preference. I'm just putting up objections to be sure we don't miss anything :) One such thing is that I seem to remember distcheck will fail in the absence of either NEWS or Changelog. I don't know if this is hard wired in the autotools chain or just because of the way our makefiles are constructed. Secondly I wonder if distro's care about either file. Individual users perhaps less so. That said, if we do continue them, then I agree that resolving NEWS won't be that hard. The worst case will be if there's been an unstable release between two stable releases, and one need only remove the === lines and add the file. I don't think ChangeLog is a big deal either: The automated generation will reflect all of the changes since the previous release on that branch, including the ones merged in from 'maint', so one can just resolve in favor of the new version and be done with it. It would be worthwhile to play around with the merge styles a bit to see which one produces the fewest conflicts. That's more or less as I see it as well. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Thursday 27 March 2014 07:45:14 John Ralls wrote: On Mar 27, 2014, at 1:47 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Tuesday 25 March 2014 09:17:29 John Ralls wrote: On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? How much overlap is there in the 'boost' and 'mvc' work ? I'm just trying to estimate if they can be done on separate branches. But perhaps you already have a vision on that. The Boost changes will touch everything because it's going to include a lot of API shrinkage, like getting rid of most of the different ways we say time, and changing object calling conventions from gnc_footype_bar(foo, baz) to foo-bar(baz). MVC is more of a refactoring exercise, pulling everything that doesn't immediately draw on the screen or get from the user out of the GUI code into a controller layer, the objective being to make switching UIs a more-or-less mechanical exercise. They'll need to be frequently merged back-and-forth with master to keep everything in sync. Do you think that will add too much extra work and that we should just do everything in master as we have been? The branching strategy in git will be an experiment for me as I never worked in an environment before that used git and a true git workflow. So my opinion on this is mostly academic. Having said that would definitely do such big refactorings on one or more separate feature branches. I'm interested in getting more familiar with how git can be leveraged to a maximum in the development cycle. If people with lots of git experience suggest that branches are the way to do this I assume they have good reason to. (Better would be of course if we fully understood these reasons ourselves but I don't feel like learning by trial and error in this case.) For one should the proposed refactorings turn out to take much more time than anticipated and we would want to ship a 2.8 with other smaller features that would be easier if the refactorings are on their own branches. That assumes of course that only atomic change sets from the feature branches can be merged into master. Not half finished features. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 27, 2014, at 8:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Thursday 27 March 2014 07:45:14 John Ralls wrote: On Mar 27, 2014, at 1:47 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Tuesday 25 March 2014 09:17:29 John Ralls wrote: On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? How much overlap is there in the 'boost' and 'mvc' work ? I'm just trying to estimate if they can be done on separate branches. But perhaps you already have a vision on that. The Boost changes will touch everything because it's going to include a lot of API shrinkage, like getting rid of most of the different ways we say time, and changing object calling conventions from gnc_footype_bar(foo, baz) to foo-bar(baz). MVC is more of a refactoring exercise, pulling everything that doesn't immediately draw on the screen or get from the user out of the GUI code into a controller layer, the objective being to make switching UIs a more-or-less mechanical exercise. They'll need to be frequently merged back-and-forth with master to keep everything in sync. Do you think that will add too much extra work and that we should just do everything in master as we have been? The branching strategy in git will be an experiment for me as I never worked in an environment before that used git and a true git workflow. So my opinion on this is mostly academic. Having said that would definitely do such big refactorings on one or more separate feature branches. I'm interested in getting more familiar with how git can be leveraged to a maximum in the development cycle. If people with lots of git experience suggest that branches are the way to do this I assume they have good reason to. (Better would be of course if we fully understood these reasons ourselves but I don't feel like learning by trial and error in this case.) For one should the proposed refactorings turn out to take much more time than anticipated and we would want to ship a 2.8 with other smaller features that would be easier if the refactorings are on their own branches. That assumes of course that only atomic change sets from the feature branches can be merged into master. Not half finished features. Yeah, unfortunately Gnome still pretty much follows the SVN model, so I don't have much experience with this either. I don't see either of these as all-or-nothing change sets, and I envision frequently merging both branches back into master. Pieces of them are: It would be dumb to have part of GnuCash using the current glib-based GncDate and part using boost::calendar::gregorian. It would be asking for serious trouble to have part using GncNumeric and part using boost::rational. But I don't see any reason, aside from timing, not to have a release with one and not the other. I read through a bunch of web articles about long-running topic branches, and most of them were negative; on the other hand, most don't like Driessen's git-flow while always remarking on its popularity. We haven't had any significant problems with private branches in the last year, so let's just keep doing it that way until we have a problem or a situation where more than one person wants to work on the same thing. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Thursday 27 March 2014 10:27:58 John Ralls wrote: On Mar 27, 2014, at 8:14 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Thursday 27 March 2014 07:45:14 John Ralls wrote: On Mar 27, 2014, at 1:47 AM, Geert Janssens janssens-ge...@telenet.be wrote: On Tuesday 25 March 2014 09:17:29 John Ralls wrote: On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? How much overlap is there in the 'boost' and 'mvc' work ? I'm just trying to estimate if they can be done on separate branches. But perhaps you already have a vision on that. The Boost changes will touch everything because it's going to include a lot of API shrinkage, like getting rid of most of the different ways we say time, and changing object calling conventions from gnc_footype_bar(foo, baz) to foo-bar(baz). MVC is more of a refactoring exercise, pulling everything that doesn't immediately draw on the screen or get from the user out of the GUI code into a controller layer, the objective being to make switching UIs a more-or-less mechanical exercise. They'll need to be frequently merged back-and-forth with master to keep everything in sync. Do you think that will add too much extra work and that we should just do everything in master as we have been? The branching strategy in git will be an experiment for me as I never worked in an environment before that used git and a true git workflow. So my opinion on this is mostly academic. Having said that would definitely do such big refactorings on one or more separate feature branches. I'm interested in getting more familiar with how git can be leveraged to a maximum in the development cycle. If people with lots of git experience suggest that branches are the way to do this I assume they have good reason to. (Better would be of course if we fully understood these reasons ourselves but I don't feel like learning by trial and error in this case.) For one should the proposed refactorings turn out to take much more time than anticipated and we would want to ship a 2.8 with other smaller features that would be easier if the refactorings are on their own branches. That assumes of course that only atomic change sets from the feature branches can be merged into master. Not half finished features. Yeah, unfortunately Gnome still pretty much follows the SVN model, so I don't have much experience with this either. I don't see either of these as all-or-nothing change sets, and I envision frequently merging both branches back into master. Pieces of them are: It would be dumb to have part of GnuCash using the current glib-based GncDate and part using boost::calendar::gregorian. It would be asking for serious trouble to have part using GncNumeric and part using boost::rational. But I don't see any reason, aside from timing, not to have a release with one and not the other. I read through a bunch of web articles about long-running topic branches, and most of them were negative; on the other hand, most don't like Driessen's git-flow while always remarking on its popularity. We haven't had any significant problems with private branches in the last year, so let's just keep doing it that way until we have a problem or a situation where more than one person wants to work on the same thing. Agreed. That a very pragmatic approach to move forward. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
--On March 27, 2014 7:25:20 AM -0700 John Ralls jra...@ceridwen.us wrote: Changelog may be more difficult though we'll have to run a test to be sure. The main question for me here is whether or not our code to generate the Changelog file can properly handle multi-parent commits ? This is important to generate log entries for the changes from upwards merged bugfixes into master. If it does, then merge conflicts when merging maint into master can always be resolved in favour of the Changelog file on master. I'm actually in favor of deleting both because I don't think that anyone ever looks at them. I expect that everyone gets the News information from the website or email if they even bother to read past the subject line, and uses the history from git log, their git GUI, or on Github to see what was committed and when. Personally, I would keep the NEWS file. I often look at these files for products I'm interested in. The ChangeLog file seems less useful, but that's just my personal opinion. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
John Ralls jra...@ceridwen.us writes: It will be. When we’re ready to release 2.8, the ‘maint’ branch will be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new ‘maint’ branch from ‘master’. We could even do that at 2.8.0, because merging ‘maint’ into ‘master’ isn’t a big deal until ‘master’ diverges. Waiting is a hold-over from SVN, which until 1.7 didn’t allow that. Why not call it ‘2.6’ right away? Just to make maintaining the wiki easier: If ‘maint’ is always the current bug-fix branch, then the policy can say that and not have to be changed every 3 years. I guess I didn't realize (or contemplate) we could easily rename the branch later -- but I suppose that makes sense based on the way that git handles branches. I'm mostly just thinking about way way way down the road someone wanting to come back and see the work done on e.g. the 2.6 maint branch, when maint isn't 2.6 anymore. Regards, John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Saturday 22 March 2014 18:39:13 John Ralls wrote: On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be wrote: Is 'stable' going to be per-release-series, i.e., will we have 'stable-2.6' and in two years 'stable-2.8'? Or do we have a single 'stable' that gets 'master' merged into it at the time of an x.x.0 release? I like the workflow as proposed in the git workflows man page (section Branch management for a release and following). They propose a long-term maintenance branch. Only when a new feature release is done, a separate maintenance branch for the previous stable series is created. So when 2.8.0 gets tagged, the current head of stable is branched off into stable-2.6. Then stable is fast forwarded to the 2.8.0 release tag. It won’t quite fast-forward because of ChangeLog and NEWS, but those are minor issues; the releaser can just resolve to the new version. It certainly looks like Changelog and NEWS are features from another era that don't map very well to modern version control systems... I suppose resolving to the new version is easiest. Do we want an integration branch (called 'next' by both examples) ? It can help predict merge conflicts and experiment with conflict resolution before merging from stable to master. Or is our team too small for that ? It can be added in a later phase as well of course. It would be an upgrade of the basic workflow, not a different workflow. ‘Next’ and ‘maint’ are just different names for ‘stable’ and ‘release’ in your original proposal. The way I understand it 'next' is neither 'stable' nor 'release'. It's a testing branch, a testbed to merge various different branches before they are merged into 'master' or 'maint'. It's a disposable branch which gets reset at each major release. But that's not so important for us - see below. As long as we’re not listening to the Github siren (the Odyssey kind, not the one on police cars) and merging directly into the public repo, there’s every opportunity to test-merge and reset back as necessary in one’s private repo and no need for a public branch on which to commit before merging. I had to read this a few times to get the sense of what you meant. I presume you were saying we shouldn't be using Github's web interface to deal with pull requests into the repositories at github.com/Gnucash. If that's what you meant, yes, I agree. I believe the intention of a public branch like next or 'pu' in the git workflow is to ensure that several features worked on in topic branches still integrate nicely. In a large project such an 'integration' branch is public because there are many developers involved and doing the integrations locally will limit what gets tested. As I suggested before the GnuCash development team seems too small to benefit from such a branch. And if needed we can always add one later on. So to start I agree we don't need an integration branch. And what names do we want to use for our public branches ? Should we just stick to the git workflow examples (maint, master, next) ? That would make it easier to refer to the man page as the reference for our workflow. I’m fine with ‘master’ and ‘maint’. Ok. So with that I think we have a good first strategy to start with. If we find details later on that don't work very well we can always adjust. If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Have you experimented at all with what the upstream looks like if you merge a private branch instead of rebasing it and then push the result? I *think* the private branch's objects will get pushed upstream, but the ref/heads entry won't, but I don't know that for sure. If I'm right, then the other change in the wiki will be to remove all of the stuff about rebasing instead of merging. On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
Branch is just a pointer to head of revisions list (node in revision tree) . So if you merge private branch in branch that is then pushed to public, it will be visible like this: http://git-scm.com/figures/18333fig0317-tn.png But without pointer to iss53 On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Have you experimented at all with what the upstream looks like if you merge a private branch instead of rebasing it and then push the result? I *think* the private branch's objects will get pushed upstream, but the ref/heads entry won't, but I don't know that for sure. If I'm right, then the other change in the wiki will be to remove all of the stuff about rebasing instead of merging. On the matter of feature branches, I'm tempted to create two public ones, 'boost' and 'mvc' to provide a long-running context to those changes and to encourage others to join the fun. A third, 'core-sql', would come after the engine has been cleaned up enough for it to be practical. What do you think? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
John Ralls jra...@ceridwen.us writes: On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Part of me thinks I'd rather see the maint branch called 2.6 -- in order to differentiate the maintenance of 2.6 vs the maint of 2.8, 3.0, etc down the road. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Tuesday 25 March 2014 13:46:17 Derek Atkins wrote: John Ralls jra...@ceridwen.us writes: On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Part of me thinks I'd rather see the maint branch called 2.6 -- in order to differentiate the maintenance of 2.6 vs the maint of 2.8, 3.0, etc down the road. -derek The git workflow proposes to only use explicit version numbers in the branches the moment you need two maintenance branches. So at the point where we want to support both a 2.6 and a 2.8 release series. Maint itself always rolls over from previous to most recent release series. In our typical workflow so far the overlap has always been very short - one or at most two point releases. So we only need to differentiate between maintenance branches for a relatively short period of time. Apart from that the release tags will also quickly reveal which branch you're on. But technically it's just a game of what's in a name. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 25, 2014, at 9:52 AM, Dmitry Pavlov zeldi...@gmail.com wrote: Branch is just a pointer to head of revisions list (node in revision tree) . So if you merge private branch in branch that is then pushed to public, it will be visible like this: http://git-scm.com/figures/18333fig0317-tn.png But without pointer to iss53 Yes, that’s what I said I thought was the case.* I’d have more confidence in that claim if the reference wasn’t figure 3.17 from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging in the section “basic merging”. Unfortunately, Chacon doesn’t explicitly cover what the history on the remote will look like when one pushes the merge of a private branch, even in http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Integrating-Contributed-Work where he covers the subject explicitly; he seems to consider only the case where all branches are pushed, and he illustrates only what the local repo looks like. Regards, John Ralls *Quibble: Not quite a pointer. More like a symbolic link in the file system or a database foreign key, because it contains the *name* of the commit, not its address. And not necessarily the head of the list; the commit pointed to may be the parent of another commit, as it is in the illustration. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 25, 2014, at 10:46 AM, Derek Atkins warl...@mit.edu wrote: John Ralls jra...@ceridwen.us writes: On Mar 25, 2014, at 8:15 AM, Geert Janssens janssens-ge...@telenet.be wrote: If no one beats me to it I'll try to adapt the git wiki page with this info in the coming days. OK. The main change seems to me to be that instead of making a '2.6' branch next week I'll be making a 'maint' branch. Part of me thinks I'd rather see the maint branch called 2.6 -- in order to differentiate the maintenance of 2.6 vs the maint of 2.8, 3.0, etc down the road. It will be. When we’re ready to release 2.8, the ‘maint’ branch will be renamed to ‘2.6’; when we release 2.8.3, we’ll create a new ‘maint’ branch from ‘master’. We could even do that at 2.8.0, because merging ‘maint’ into ‘master’ isn’t a big deal until ‘master’ diverges. Waiting is a hold-over from SVN, which until 1.7 didn’t allow that. Why not call it ‘2.6’ right away? Just to make maintaining the wiki easier: If ‘maint’ is always the current bug-fix branch, then the policy can say that and not have to be changed every 3 years. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
As I said, you'll just see a fork and merge but without identification of private branch. I made a small local example and the result: * 124d38e (HEAD, origin/master, master) Merge branch 'private' |\ | * cbcff86 change in private * | ebe2dec another commit in master * | 4bfde8e change in master |/ * 9b2b43b initial full prompt of the process with upstream repos and two dev is in attachment 2014-03-25 22:00 GMT+04:00 John Ralls jra...@ceridwen.us: On Mar 25, 2014, at 9:52 AM, Dmitry Pavlov zeldi...@gmail.com wrote: Branch is just a pointer to head of revisions list (node in revision tree) . So if you merge private branch in branch that is then pushed to public, it will be visible like this: http://git-scm.com/figures/18333fig0317-tn.png But without pointer to iss53 Yes, that’s what I said I thought was the case.* I’d have more confidence in that claim if the reference wasn’t figure 3.17 from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging in the section “basic merging”. Unfortunately, Chacon doesn’t explicitly cover what the history on the remote will look like when one pushes the merge of a private branch, even in http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Integrating-Contributed-Workwhere he covers the subject explicitly; he seems to consider only the case where all branches are pushed, and he illustrates only what the local repo looks like. Regards, John Ralls *Quibble: Not quite a pointer. More like a symbolic link in the file system or a database foreign key, because it contains the *name* of the commit, not its address. And not necessarily the head of the list; the commit pointed to may be the parent of another commit, as it is in the illustration. -- С уважением, Дмитрий Павлов dmitry@acernt:/tmp$ mkdir git-tests dmitry@acernt:/tmp$ cd git-tests/ dmitry@acernt:/tmp/git-tests$ mkdir upstream dmitry@acernt:/tmp/git-tests$ cd upstream/ dmitry@acernt:/tmp/git-tests/upstream$ git init --bare Initialized empty Git repository in /tmp/git-tests/upstream/ dmitry@acernt:/tmp/git-tests/upstream$ cd .. dmitry@acernt:/tmp/git-tests$ rmdir a b dmitry@acernt:/tmp/git-tests$ git clone upstream a Cloning into 'a'... done. warning: You appear to have cloned an empty repository. dmitry@acernt:/tmp/git-tests$ git clone upstream b Cloning into 'b'... done. warning: You appear to have cloned an empty repository. dmitry@acernt:/tmp/git-tests$ cd a dmitry@acernt:/tmp/git-tests/a$ touch a b c dmitry@acernt:/tmp/git-tests/a$ git add a b c dmitry@acernt:/tmp/git-tests/a$ git commit -m initial [master (root-commit) 9b2b43b] initial 0 files changed create mode 100644 a create mode 100644 b create mode 100644 c dmitry@acernt:/tmp/git-tests/a$ git push origin master Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 213 bytes, done. Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. To /tmp/git-tests/upstream * [new branch] master - master dmitry@acernt:/tmp/git-tests/a$ cd ../b dmitry@acernt:/tmp/git-tests/b$ git pull remote: Counting objects: 3, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From /tmp/git-tests/upstream * [new branch] master - origin/master dmitry@acernt:/tmp/git-tests/b$ git branch * master dmitry@acernt:/tmp/git-tests/b$ git checkout -b private Switched to a new branch 'private' dmitry@acernt:/tmp/git-tests/b$ echo private branch change b dmitry@acernt:/tmp/git-tests/b$ git add b dmitry@acernt:/tmp/git-tests/b$ git commit -m change in private [private cbcff86] change in private 1 file changed, 1 insertion(+) dmitry@acernt:/tmp/git-tests/b$ git checkout master Switched to branch 'master' dmitry@acernt:/tmp/git-tests/b$ echo change in master a dmitry@acernt:/tmp/git-tests/b$ git add a dmitry@acernt:/tmp/git-tests/b$ git commit -m change in master [master 4bfde8e] change in master 1 file changed, 1 insertion(+) dmitry@acernt:/tmp/git-tests/b$ echo another change c dmitry@acernt:/tmp/git-tests/b$ git add c dmitry@acernt:/tmp/git-tests/b$ git commit -m another commit in master [master ebe2dec] another commit in master 1 file changed, 1 insertion(+) dmitry@acernt:/tmp/git-tests/b$ git merge private Merge made by the 'recursive' strategy. b |1 + 1 file changed, 1 insertion(+) dmitry@acernt:/tmp/git-tests/b$ git push origin master Counting objects: 13, done. Delta compression using up to 4 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (11/11), 1.02 KiB, done. Total 11 (delta 1), reused 0 (delta 0) Unpacking objects: 100% (11/11), done. To /tmp/git-tests/upstream 9b2b43b..124d38e master - master dmitry@acernt:/tmp/git-tests/b$ git branch * master private dmitry@acernt:/tmp/git-tests/b$ cd ../a dmitry@acernt:/tmp/git-tests/a$ git pull remote: Counting objects: 13, done
Re: Branching strategy for git
On Mar 25, 2014, at 11:35 AM, Dmitry Pavlov zeldi...@gmail.com wrote: As I said, you'll just see a fork and merge but without identification of private branch. I made a small local example and the result: * 124d38e (HEAD, origin/master, master) Merge branch 'private' |\ | * cbcff86 change in private * | ebe2dec another commit in master * | 4bfde8e change in master |/ * 9b2b43b initial full prompt of the process with upstream repos and two dev is in attachment Thanks for running the test to confirm it. Regards, John Ralls 2014-03-25 22:00 GMT+04:00 John Ralls jra...@ceridwen.us: On Mar 25, 2014, at 9:52 AM, Dmitry Pavlov zeldi...@gmail.com wrote: Branch is just a pointer to head of revisions list (node in revision tree) . So if you merge private branch in branch that is then pushed to public, it will be visible like this: http://git-scm.com/figures/18333fig0317-tn.png But without pointer to iss53 Yes, that’s what I said I thought was the case.* I’d have more confidence in that claim if the reference wasn’t figure 3.17 from http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging in the section “basic merging”. Unfortunately, Chacon doesn’t explicitly cover what the history on the remote will look like when one pushes the merge of a private branch, even in http://git-scm.com/book/en/Distributed-Git-Maintaining-a-Project#Integrating-Contributed-Work where he covers the subject explicitly; he seems to consider only the case where all branches are pushed, and he illustrates only what the local repo looks like. Regards, John Ralls *Quibble: Not quite a pointer. More like a symbolic link in the file system or a database foreign key, because it contains the *name* of the commit, not its address. And not necessarily the head of the list; the commit pointed to may be the parent of another commit, as it is in the illustration. -- С уважением, Дмитрий Павлов private-branch-merge.txt ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Branching strategy for git
This topic has been brought up before but we never really came to a consensus on how we want to organize our branches in the official git repository. Yet I want to get a final decision on this before we open a master for feature development again. To refresh memory here is a link to the thread on gnucash-devel last year January about this topic: http://lists.gnucash.org/pipermail/gnucash-devel/2013-January/034843.html The model I defended in that thread is more or less this (quoted from http://lists.gnucash.org/pipermail/gnucash-devel/2013-February/034878.html ) - one branch for future development (features, refactoring, anything too complex for a stable release) - there can be subbranches for separate features or refactoring efforts that get merged into the main development branch when they are considered ready - one branch for stable development (bugfixes, translation updates). This branch gets merged into development regularly to get all bugfixes into the future development as well - one release branch. The only direct commits here are those purely related to releasing, like updating the version number. Other than that it receives bugfixes and translation updates merged in from the stable branch. This setup leverages the git history to keep track of which changes go where. It solves the problem of forgotten backports (there no longer are any) and makes sure that all bugfixes eventually end up in all branches that should carry them. This obsoletes our current BP/AUDIT machinery which was adopted because svn history was not capable of managing this on its own. At some point we had some kind of a gatekeeper to tell which bugfixes were allowed on stable and which aren't. This person tracked the AUDIT mails to know which commits to verify. If we want to re-establish this function in the future I think the easiest way would be as follows: - only the gatekeeper can push to the central stable branch. - bugfixes are done on their local stable branches and they send pull requests (or patches) for review to the gatekeeper - the gatekeeper evaluates the pull requests/patches and accepts or rejects. Using pull requests once more leverages one of the powers of git. Since that long-winded thread I have found some workflows as recommended by other projects managed in git. I have collected some links to such workflows in our wiki [1]. Reading those you will find they all more or less start on a similar basis. I find it rather amusing we got to such a similar result by independently thinking about this. Some workflows add more branches in the mix, like an integration branch. We may want to discuss if those extra's make sense in the small team we currently are. Please give your feedback on whether or not we want to adopt such a workflow. If so we really need to review the Backporting stuff on our Git wiki page. Geert [1] http://wiki.gnucash.org/wiki/Git#Branching_and_Merging ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Branching strategy for git
On Mar 22, 2014, at 3:24 AM, Geert Janssens janssens-ge...@telenet.be wrote: This topic has been brought up before but we never really came to a consensus on how we want to organize our branches in the official git repository. Yet I want to get a final decision on this before we open a master for feature development again. To refresh memory here is a link to the thread on gnucash-devel last year January about this topic: http://lists.gnucash.org/pipermail/gnucash-devel/2013-January/034843.html The model I defended in that thread is more or less this (quoted from http://lists.gnucash.org/pipermail/gnucash-devel/2013-February/034878.html ) - one branch for future development (features, refactoring, anything too complex for a stable release) - there can be subbranches for separate features or refactoring efforts that get merged into the main development branch when they are considered ready - one branch for stable development (bugfixes, translation updates). This branch gets merged into development regularly to get all bugfixes into the future development as well - one release branch. The only direct commits here are those purely related to releasing, like updating the version number. Other than that it receives bugfixes and translation updates merged in from the stable branch. This setup leverages the git history to keep track of which changes go where. It solves the problem of forgotten backports (there no longer are any) and makes sure that all bugfixes eventually end up in all branches that should carry them. This obsoletes our current BP/AUDIT machinery which was adopted because svn history was not capable of managing this on its own. At some point we had some kind of a gatekeeper to tell which bugfixes were allowed on stable and which aren't. This person tracked the AUDIT mails to know which commits to verify. If we want to re-establish this function in the future I think the easiest way would be as follows: - only the gatekeeper can push to the central stable branch. - bugfixes are done on their local stable branches and they send pull requests (or patches) for review to the gatekeeper - the gatekeeper evaluates the pull requests/patches and accepts or rejects. Using pull requests once more leverages one of the powers of git. Since that long-winded thread I have found some workflows as recommended by other projects managed in git. I have collected some links to such workflows in our wiki [1]. Reading those you will find they all more or less start on a similar basis. I find it rather amusing we got to such a similar result by independently thinking about this. Some workflows add more branches in the mix, like an integration branch. We may want to discuss if those extra's make sense in the small team we currently are. Please give your feedback on whether or not we want to adopt such a workflow. If so we really need to review the Backporting stuff on our Git wiki page. I think the key point from that earlier discussion is that git merge is a lot more powerful than is apparent on the surface. One example is 'rerere' [1], which was mentioned in passing in the Petsc branching article you linked on the wiki. I wasn't aware of that option until now, but contrary to the implications of the Petsc mention, it must be deliberately enabled. There's a lot of good insight in the git workflows manpage [2], also linked in the wiki, including some rules about managing what to merge into which branch. One of the more interesting of those is the recommendation to fix bugs in the *most stable* branch and merge upwards. That's consistent with your 'stable' branch recommendation. There are two things about a separate release branch containing only the release commits that require a bit more thought: 1. Those commits have 3 changes: The version number in configure.ac, the git log - ChangeLog, and the release blurb summarizing the bug fixes and translation updates in NEWS. One could argue persuasively that NEWS and ChangeLog are obsolete thanks to git's vastly better logging facility and that we should just remove them. If we decide not to do that, we'll need to figure out a branching strategy that carries them into new release branches. Regardless, the 'stable' branch needs to have *something* in AC_INIT. What should that be? 2. The release tags will be on the release branch, so `git describe` will make sense only there. The same is true for history on Github, which admittedly doesn't do a good job of highlighting tags anyway. They will show up in the 'network' display there (though that's so slow I seldom use it) and in a multi-branch display in any of the graphical repo browsers, so maybe this isn't a big deal. What are the implications of not doing a separate release branch and doing releases from 'stable', more or less as we do now? Only that every time we merge
Re: Branching strategy for git
On Saturday 22 March 2014 10:18:42 John Ralls wrote: On Mar 22, 2014, at 3:24 AM, Geert Janssens janssens-ge...@telenet.be wrote: This topic has been brought up before but we never really came to a consensus on how we want to organize our branches in the official git repository. Yet I want to get a final decision on this before we open a master for feature development again. To refresh memory here is a link to the thread on gnucash-devel last year January about this topic: http://lists.gnucash.org/pipermail/gnucash-devel/2013-January/034843 .html The model I defended in that thread is more or less this (quoted from http://lists.gnucash.org/pipermail/gnucash-devel/2013-February/03487 8.html ) - one branch for future development (features, refactoring, anything too complex for a stable release) - there can be subbranches for separate features or refactoring efforts that get merged into the main development branch when they are considered ready - one branch for stable development (bugfixes, translation updates). This branch gets merged into development regularly to get all bugfixes into the future development as well - one release branch. The only direct commits here are those purely related to releasing, like updating the version number. Other than that it receives bugfixes and translation updates merged in from the stable branch. This setup leverages the git history to keep track of which changes go where. It solves the problem of forgotten backports (there no longer are any) and makes sure that all bugfixes eventually end up in all branches that should carry them. This obsoletes our current BP/AUDIT machinery which was adopted because svn history was not capable of managing this on its own. At some point we had some kind of a gatekeeper to tell which bugfixes were allowed on stable and which aren't. This person tracked the AUDIT mails to know which commits to verify. If we want to re-establish this function in the future I think the easiest way would be as follows: - only the gatekeeper can push to the central stable branch. - bugfixes are done on their local stable branches and they send pull requests (or patches) for review to the gatekeeper - the gatekeeper evaluates the pull requests/patches and accepts or rejects. Using pull requests once more leverages one of the powers of git. Since that long-winded thread I have found some workflows as recommended by other projects managed in git. I have collected some links to such workflows in our wiki [1]. Reading those you will find they all more or less start on a similar basis. I find it rather amusing we got to such a similar result by independently thinking about this. Some workflows add more branches in the mix, like an integration branch. We may want to discuss if those extra's make sense in the small team we currently are. Please give your feedback on whether or not we want to adopt such a workflow. If so we really need to review the Backporting stuff on our Git wiki page. I think the key point from that earlier discussion is that git merge is a lot more powerful than is apparent on the surface. One example is 'rerere' [1], which was mentioned in passing in the Petsc branching article you linked on the wiki. I wasn't aware of that option until now, but contrary to the implications of the Petsc mention, it must be deliberately enabled. I hadn't heard of rerere either. Looks like a very useful support tool. If I understand correctly, it's a local-only tool. rerere cache doesn't propagate with pushes or pulls. Which means that if one contributor has a rerere cache on his local machine to get his feature branch merged into the development branch, this cache is not available to you or me when we try to merge a pull request. That's probably why the git workflow man page suggests the integrator can ask a feature author to perform the merge. There's a lot of good insight in the git workflows manpage [2], also linked in the wiki, including some rules about managing what to merge into which branch. One of the more interesting of those is the recommendation to fix bugs in the *most stable* branch and merge upwards. That's consistent with your 'stable' branch recommendation. There are two things about a separate release branch containing only the release commits that require a bit more thought: 1. Those commits have 3 changes: The version number in configure.ac, the git log - ChangeLog, and the release blurb summarizing the bug fixes and translation updates in NEWS. One could argue persuasively that NEWS and ChangeLog are obsolete thanks to git's vastly better logging facility and that we should just remove them. If we decide not to do that, we'll need to figure out a branching strategy that carries them into new release branches. Regardless, the 'stable' branch needs to have *something
Re: Branching strategy for git
On Mar 22, 2014, at 4:01 PM, Geert Janssens janssens-ge...@telenet.be wrote: On Saturday 22 March 2014 10:18:42 John Ralls wrote: There are two things about a separate release branch containing only the release commits that require a bit more thought: 1. Those commits have 3 changes: The version number in configure.ac, the git log - ChangeLog, and the release blurb summarizing the bug fixes and translation updates in NEWS. One could argue persuasively that NEWS and ChangeLog are obsolete thanks to git's vastly better logging facility and that we should just remove them. If we decide not to do that, we'll need to figure out a branching strategy that carries them into new release branches. Regardless, the 'stable' branch needs to have *something* in AC_INIT. What should that be? 2. The release tags will be on the release branch, so `git describe` will make sense only there. The same is true for history on Github, which admittedly doesn't do a good job of highlighting tags anyway. They will show up in the 'network' display there (though that's so slow I seldom use it) and in a multi-branch display in any of the graphical repo browsers, so maybe this isn't a big deal. In the git workflows man page the release tags can be on either the development branch or the maintenance branch. The release tag should be attached to whatever commit is used to make the tarball. If we’re releasing directly off of the maint or master branches (per where you settled out later), then none of this is a concern. What are the implications of not doing a separate release branch and doing releases from 'stable', more or less as we do now? Only that every time we merge 'stable' to 'master' after a release there will be a conflict at the AC_INIT line because the version number in 'master' will be either 2.6.99 or 2.7.x. That conflict always gets resolved in favor of 'master'. NEWS and ChangeLog will fast-forward until we start doing unstable releases from 'master', after which they'll have to be hand-merged. I think that's less work and produces clearer history than separating the 'stable' and 'release' branches. I'm fine with not doing a separate release branch. This came up in the earlier discussion to allow for a gatekeeper role. But there are other ways to do that. The petsc workflow calls this 'gatekeeper' a maintainer. By limiting commit access to one or a few people on the stable branch, you can equally have control over what goes into stable or not. From that point of view I agree that having a separate branch for stable development and releases is more overhead than benefit. All of the guidance and discussion so far has been in the context of 'fix bugs and add features' development, but we're planning major architectural and language changes that are going to diverge 'master' from 'stable' rather radically. Ideally that would mean that many bug fixes won't need to be merged up because the bug won't exist in 'master', but the reality is more likely to be that it does, but the solution must be written differently. Do we still do the merge and make the new version a conflict resolution? I think you can't skip the merge in such cases. Future commits on stable that you do want to merge (in code that is still similar between the branches for example) will pull in the merge conflict anyway. How exactly to handle the merge will probably depend a little on the issue at hand and the git knowledge of the person doing the merge. The one-commit approach would be merge-resolve conflicts-commit resolved merge. If the stable fix has no resemblance anymore with what's needed on devel to get the same bug fixed we might also do a merge dropping all stable branch changes for that fix, then add a new commit with the proper fix after the merge. The second option feels more cluttered though and makes it harder to read the history later on. So I'd prefer to do the fix straight away in the merge commit when possible. Always. ;-) “When possible” is of course the catch. Is 'stable' going to be per-release-series, i.e., will we have 'stable-2.6' and in two years 'stable-2.8'? Or do we have a single 'stable' that gets 'master' merged into it at the time of an x.x.0 release? I like the workflow as proposed in the git workflows man page (section Branch management for a release and following). They propose a long-term maintenance branch. Only when a new feature release is done, a separate maintenance branch for the previous stable series is created. So when 2.8.0 gets tagged, the current head of stable is branched off into stable-2.6. Then stable is fast forwarded to the 2.8.0 release tag. It won’t quite fast-forward because of ChangeLog and NEWS, but those are minor issues; the releaser can just resolve to the new version. This looks like a good approach to me as it allows us to do what
Re: Strategy for deleting wiki spam pages
As a non- (or not-yet-) developer who has tinkered with several pages in the GnuCash wiki over several years I hope you don't mind if I weigh in briefly on this discussion... [My password database says I created the twt username in 2008.] On Sat, Aug 10, 2013 at 4:13 PM, Christian Stimming christ...@cstimming.de wrote: Other wikis around have disabled the normal user registration altogether for this very same reason, see e.g. http://elinux.org/Main_Page . Maybe this is a possibility for us as well? The vast majority of edits in the actual content is done by known developers from here. By this, we can argue that an increased restriction of the write access doesn't do much harm, but would make our life a lot easier. I am all for making it a lot easier. I really appreciate the work it must take to prune such frequent spam from the wiki. Since I am NOT a known developer, however, I am concerned how I and other people who haven't (yet) contributed code might be reasonably validated for editing the wiki. I am also concerned how admins might reasonably prune or restrict the EXISTING wiki userbase. If my wiki account was compromised I would completely understand being shut out, but a few months of inactivity between edits could easily describe my normal behavior on the GnuCash wiki. :-) On Sat, Aug 10, 2013 at 6:59 PM, John Ralls jra...@ceridwen.us wrote: On Aug 10, 2013, at 4:13 PM, John Ralls jra...@ceridwen.us wrote: I'm absolutely in favor of taking a more aggressive approach. By shutting off the normal registration, do you mean that new users would require an administrator to validate them? The mediawiki manual has a long page on preventing and removing spam: http://www.mediawiki.org/wiki/Manual:Combating_spam with links to other pages with still more information on the subject. I read the mediawiki page referenced above and it seems to me (unless some more automated solution can be devised) maybe the gated community solution they describe would not be too terrible. I don't know how it looks from the admin side, but I don't believe the hurdle of requesting permission would have stopped me from taking on the few pages I have worked on. On the downside, it pushes the spam vs. ham task to a wiki admin who might rather not have registration validation added to their plate. By the way, it was a pain when the GnuCash wiki started making me re-capcha my edits every time I update pages with links. HOWEVER if it deters even one spambot then it probably deters hundreds of others and I can live with it. But if I could get it turned off by getting on a trusted list I would appreciate it. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy for deleting wiki spam pages
Am Samstag, 10. August 2013, 16:13:30 schrieb John Ralls: Christian, I get notified of changes via RSS to http://wiki.gnucash.org/wiki/Special:NewPages rather than RecentChanges, and I check my RSS reader 2-3 times a day. I don't remember seeing any spammer-user who'd created a user page, and when I follow the link to one that isn't blocked, I see the not created message and have no option to delete it. I looked at the last 2000 users who have edits and found none with User pages.Yet you delete a user page for everyone you block. What am I missing? I think the RSS feed only shows the RecentChanges in the (Main) namespace [1], which does not include the user pages. I look at the RecentChanges in the all namespace [2] , which makes it harder to read, but shows some new pages in the User namespace. In this view, I see the leftover spam user page creations. I delete those and block the respective user, just as you delete the normal pages and block those users. I'm absolutely in favor of taking a more aggressive approach. By shutting off the normal registration, do you mean that new users would require an administrator to validate them? That's how I understand it, yes. I haven't found time to read the additional information from mediawiki.org. Maybe there are technical solutions to this, but if not, I'd prefer administrator validation over the continuous spam pages. Regards, Christian Regards John Ralls [1] http://wiki.gnucash.org/wiki/index.php?namespace=0title=Special%3ARecentChanges [2] http://wiki.gnucash.org/wiki/index.php?namespace=limit=250title=Special%3ARecentChanges ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy for deleting wiki spam pages
On Aug 11, 2013, at 12:51 PM, Christian Stimming christ...@cstimming.de wrote: Am Samstag, 10. August 2013, 16:13:30 schrieb John Ralls: Christian, I get notified of changes via RSS to http://wiki.gnucash.org/wiki/Special:NewPages rather than RecentChanges, and I check my RSS reader 2-3 times a day. I don't remember seeing any spammer-user who'd created a user page, and when I follow the link to one that isn't blocked, I see the not created message and have no option to delete it. I looked at the last 2000 users who have edits and found none with User pages.Yet you delete a user page for everyone you block. What am I missing? I think the RSS feed only shows the RecentChanges in the (Main) namespace [1], which does not include the user pages. I look at the RecentChanges in the all namespace [2] , which makes it harder to read, but shows some new pages in the User namespace. In this view, I see the leftover spam user page creations. I delete those and block the respective user, just as you delete the normal pages and block those users. Yes, I figured that out. It also doesn't show me edited pages, so I've been missing spam that's added to existing pages as well. I'm absolutely in favor of taking a more aggressive approach. By shutting off the normal registration, do you mean that new users would require an administrator to validate them? That's how I understand it, yes. I haven't found time to read the additional information from mediawiki.org. Maybe there are technical solutions to this, but if not, I'd prefer administrator validation over the continuous spam pages. OK. It looks like the easiest way to do that is to remove the create user privilege from All, but then users will have to ask on the mailing list and we'll need to delete the several bazillion bogus users... and I don't see any interface visible to me for doing that. Ah, there's an extension for getting rid of all of the accounts which have never done an edit: http://www.mediawiki.org/wiki/Manual:RemoveUnusedAccounts.php Maybe run that once a month? For the bad accounts that have made edits, the procedure's a bit more complex: http://www.mediawiki.org/wiki/Manual:Preventing_access#Removing_accounts but they should all be blocked anyway. Next alternative would be to create a class of user called editor; if you select show only users with edits and sort by creation date on http://wiki.gnucash.org/wiki/Special:ListUsers it shows quite a few people with that next to their names. Page creation and editing could be limited to members of that group, and maybe Administrators could be given permission to move properly authenticated users into it. The relevant manual page is http://www.mediawiki.org/wiki/Manual:User_rights_management Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Strategy for deleting wiki spam pages
Hi John, I noticed you regularly delete spam pages in our wiki, which is a very good thing to do. As you and I and hopefully others have noticed, we now get approx. 1-5 spam pages created every day, which have to be deleted manually. This is even though new pages can be created by users who have been registered for more than x days. However, once you check the RecentChanges with a view mode that shows the new user registrations, we notice that every day there are approx. 50 new users being registered! Some of these will stay silent for a few days, then - after the waiting period is over - create the spam page. This way, the waiting period does nothing more than reducing the spam rate, but it doesn't cut it off completely anymore. This is the same for several months by now. I also don't have a good solution for this. I think I can contribute to a check of the RecentChanges every 1-3 days, so that this spam is deleted manually. (The keyboard shortcuts help a bit: Alt-Shift-D for choosing the page's hyperlink for Delete this page, then Ctrl-A, Del for deleting the deletion reason, then Tab-Tab-Enter for really pressing the delete button, and all this with many browser tabs in parallel between which I navigate with Ctrl-PgUp/Down.) However, I noticed in your spam deletions that you deleted only the normal pages, but not the user pages of those spammers. Probably you look at the RecentChanges page only with the subset of Namespace = (Main). I look at this page with the choice Namespace = all. The backside of this is that I see those 100 new users every day and the edits scattered in between. The upside is that I see also the newly created spam userpages (in the User: namespace), and then I delete those as well. Do you think you can check for those as well, or do we need other solutions for this? Other wikis around have disabled the normal user registration altogether for this very same reason, see e.g. http://elinux.org/Main_Page . Maybe this is a possibility for us as well? The vast majority of edits in the actual content is done by known developers from here. By this, we can argue that an increased restriction of the write access doesn't do much harm, but would make our life a lot easier. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy for deleting wiki spam pages
On Aug 10, 2013, at 2:13 PM, Christian Stimming christ...@cstimming.de wrote: Hi John, I noticed you regularly delete spam pages in our wiki, which is a very good thing to do. As you and I and hopefully others have noticed, we now get approx. 1-5 spam pages created every day, which have to be deleted manually. This is even though new pages can be created by users who have been registered for more than x days. However, once you check the RecentChanges with a view mode that shows the new user registrations, we notice that every day there are approx. 50 new users being registered! Some of these will stay silent for a few days, then - after the waiting period is over - create the spam page. This way, the waiting period does nothing more than reducing the spam rate, but it doesn't cut it off completely anymore. This is the same for several months by now. I also don't have a good solution for this. I think I can contribute to a check of the RecentChanges every 1-3 days, so that this spam is deleted manually. (The keyboard shortcuts help a bit: Alt-Shift-D for choosing the page's hyperlink for Delete this page, then Ctrl-A, Del for deleting the deletion reason, then Tab-Tab-Enter for really pressing the delete button, and all this with many browser tabs in parallel between which I navigate with Ctrl-PgUp/Down.) However, I noticed in your spam deletions that you deleted only the normal pages, but not the user pages of those spammers. Probably you look at the RecentChanges page only with the subset of Namespace = (Main). I look at this page with the choice Namespace = all. The backside of this is that I see those 100 new users every day and the edits scattered in between. The upside is that I see also the newly created spam userpages (in the User: namespace), and then I delete those as well. Do you think you can check for those as well, or do we need other solutions for this? Other wikis around have disabled the normal user registration altogether for this very same reason, see e.g. http://elinux.org/Main_Page . Maybe this is a possibility for us as well? The vast majority of edits in the actual content is done by known developers from here. By this, we can argue that an increased restriction of the write access doesn't do much harm, but would make our life a lot easier. Christian, I get notified of changes via RSS to http://wiki.gnucash.org/wiki/Special:NewPages rather than RecentChanges, and I check my RSS reader 2-3 times a day. I don't remember seeing any spammer-user who'd created a user page, and when I follow the link to one that isn't blocked, I see the not created message and have no option to delete it. I looked at the last 2000 users who have edits and found none with User pages.Yet you delete a user page for everyone you block. What am I missing? I'm absolutely in favor of taking a more aggressive approach. By shutting off the normal registration, do you mean that new users would require an administrator to validate them? Regards John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy for deleting wiki spam pages
On Aug 10, 2013, at 4:13 PM, John Ralls jra...@ceridwen.us wrote: On Aug 10, 2013, at 2:13 PM, Christian Stimming christ...@cstimming.de wrote: Hi John, I noticed you regularly delete spam pages in our wiki, which is a very good thing to do. As you and I and hopefully others have noticed, we now get approx. 1-5 spam pages created every day, which have to be deleted manually. This is even though new pages can be created by users who have been registered for more than x days. However, once you check the RecentChanges with a view mode that shows the new user registrations, we notice that every day there are approx. 50 new users being registered! Some of these will stay silent for a few days, then - after the waiting period is over - create the spam page. This way, the waiting period does nothing more than reducing the spam rate, but it doesn't cut it off completely anymore. This is the same for several months by now. I also don't have a good solution for this. I think I can contribute to a check of the RecentChanges every 1-3 days, so that this spam is deleted manually. (The keyboard shortcuts help a bit: Alt-Shift-D for choosing the page's hyperlink for Delete this page, then Ctrl-A, Del for deleting the deletion reason, then Tab-Tab-Enter for really pressing the delete button, and all this with many browser tabs in parallel between which I navigate with Ctrl-PgUp/Down.) However, I noticed in your spam deletions that you deleted only the normal pages, but not the user pages of those spammers. Probably you look at the RecentChanges page only with the subset of Namespace = (Main). I look at this page with the choice Namespace = all. The backside of this is that I see those 100 new users every day and the edits scattered in between. The upside is that I see also the newly created spam userpages (in the User: namespace), and then I delete those as well. Do you think you can check for those as well, or do we need other solutions for this? Other wikis around have disabled the normal user registration altogether for this very same reason, see e.g. http://elinux.org/Main_Page . Maybe this is a possibility for us as well? The vast majority of edits in the actual content is done by known developers from here. By this, we can argue that an increased restriction of the write access doesn't do much harm, but would make our life a lot easier. Christian, I get notified of changes via RSS to http://wiki.gnucash.org/wiki/Special:NewPages rather than RecentChanges, and I check my RSS reader 2-3 times a day. I don't remember seeing any spammer-user who'd created a user page, and when I follow the link to one that isn't blocked, I see the not created message and have no option to delete it. I looked at the last 2000 users who have edits and found none with User pages.Yet you delete a user page for everyone you block. What am I missing? I'm absolutely in favor of taking a more aggressive approach. By shutting off the normal registration, do you mean that new users would require an administrator to validate them? The mediawiki manual has a long page on preventing and removing spam: http://www.mediawiki.org/wiki/Manual:Combating_spam with links to other pages with still more information on the subject. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
Am Samstag, 3. Dezember 2011, 16:40:07 schrieb Donald Allen: I've been watching with interest the messages flying by from various people that confirm the impression (from just trying to build it) that Gnucash has become a gigantic hairball. John Ralls has been saying a number of things that sound smart (I'll tell you later where to send the check, John) about design errors, problems in the data model, etc., and has embarked upon a re-design. Christian has taken a similar step back with Cutecash. Then there's the whole issue of the use of Scheme. Much as I love the elegance of the language, I doubt that its use is appropriate here, for all the reasons that we've discussed ad nauseum. So I'd like to suggest that perhaps none of the proposed ways-forward are radical enough. Thanks for the thoughts about the current project progress as observed from reading here. From my point of view there isn't any immediate need for a more radical way of moving forward. Instead, there have been identified several ways of incrementally introducing more modern programming tools / models / languages, and using those for improving the user experience. After all, the main goal of the project is a software that will do what the users want (even though the actual target user group is still up to debate). That is, the main goal is *not* to use the hottest programming languages of choice, or something similar. It's what the users get to see that counts. From that point of view, the internal changes aren't as important. And in my opinion this is enough reason to keep the internal changes incremental, which is very well possible. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
I can tell you that GnuCash is rock solid and reliable. It may be boring, but it is really stable and really good. To some degree, as long as it continues to be this good, it really doesn't matter what is in the hairball, it must be good too :) Think about how many flawless backups GnuCash makes over the course of the day, every day.. for years, thousands and then some.. this kind of thing doesn't get much praise, but when you find yourself in the kind of mess that you learn about what is going on, it is such a relief that someone thought about it before you even needed it! Starting over, by definition, will be more complicated than continuing. It's like saying we need to make a bigger hairball because working with the current one is going to be even harder, not sure it could be--IF all other things are kept equal. Now, if you throw out a bunch of features, compatibility, reliability, and stability.. then you might be able to come upon another program that could be considered a good start, for a time (until it becomes a hairball) and possibly, for a reduced user base, sacrifice one or all of the mentioned features. I know this is all with the best of intentions for sure, but it just won't make for the best return. Formerly I was user of quickbooks, and our company counted on this software. (BTW, it only ask you to backup every n times you close the file, and really, I mean, it just said would you like to? no was the usual answer, who has time to wait for it to do whatever it is doing..) One of the things that would really burn me up was that we would spend a whole year slaving over the program entering our precious data, only to see it become a ball and chain. Each year we would have to buy back our freedom for another year.. Features would stop working by design (payroll will not be supported after...), or another new hardware or software would push us to another os version which would cause some problem, and of course we pay for premium support , only to find that the answer was always simple, this version doesn't support that configuration, you will have to upgrade. Countless times we decided to jump ship only to find that the cost of the old data was too great. Running two systems parallel is not efficient, paying to convert the old data to a new system is not reasonable. So there we were, watching our own effort used against us to extract more money, each year only adding to the problem. From that perspective GnuCash both in it's current form, and direction, is really good. Much effort is put into compatibility between the latest versions and the older versions. You can't be imprisoned by your own data, as the file can be opened and read in plain text, the project doesn't build walls around the data, but instead makes it very open. If it all started over from scratch compatibility with the current project would be a requirement if it was expected that the current installed base would migrate, and I would say you wouldn't have a high percentage, even being optimistic, there are too many ways to go, and the new version would just be one of many ways to go, and a less experienced way at that. If all the developers quit at one time, even then, I don't think the project could stop, there are too many people with an interest in it continuing, and they would just pick up and go. This is the really safe, and really nice thing about a project that is truly open. It's not like some projects, where the team develops a really good product, but you have to pay to receive the good product, if you are interested in the open source version, you'll find it out of date, behind in features, and with small glitches here and there.. (that's ok, you can always pay for the shiny new version.. or buy support) With GnuCash the whole thing is right there, not secret, not for a select few, for anyone and everyone, and for free! -Bob ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
Better to either imbed Guile in the executable or start replacing it piece by piece. Too many dependencies on other peoples work. Mentor Graphics faced the same problem with 16,000,000 lines of source code for one product written in several languages. They laid off the US help and sent the code to India... An object oriented data design should be done first.. Tedc On Sat, Dec 3, 2011 at 7:38 PM, Ross Boylan rossboy...@stanfordalumni.orgwrote: On Sat, 2011-12-03 at 16:40 -0500, Donald Allen wrote: The big question is, when is it worth it to cut your losses and start over? I don't have strong opinions, but others do, in the opposite direction: Joel Spolsky says (in the context of Netsape) single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. and also As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. It's a big hairy mess, they will tell you. I'd like nothing better than to throw it out and start over. There's more in his essay Things You Should Never Do http://www.joelonsoftware.com/articles/fog69.html Ross Boylan ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On 03 Dec 2011, at 11:40 PM, Donald Allen wrote: Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I use gnucash because a) it's been around a long time, and b) because gnucash is likely to be around a long time still. Anyone can start over at any time - that's called a new product - but when people decide to abandon what they have and start over, that's when you lose faith in the project and start to look somewhere else. Sure, new fandangled languages are shiny, but will they still be popular in 5 years? No idea. I am happy to bet that C will be around in 5 years, so investing in the language as unsexy as it might be for me is a good investment. I think gnucash needs a heavy set of refactoring. I'd like to see a proper libgnucash split out as a separate library that I can depend on in other software. I'd like to use a libgnucash library as a basis for a restful service that will allow me to share gnucash with others, like my accountant. But I don't think gnucash needs to be started over. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
As with Donald, I haven't contributed any code, but I would tend to agree that there is a problem. A rewrite from scratch is a drastic solution to that not quite as drastic problem. The roadmap on the Wiki is more like a wishlist, and the schedule is, well, non existent. Sorry, I see that there is a documented and very wide guideline, but the history doesn't show that being hit. And maybe bug fix releases should be an as-needed basis; regardless, its indication of a problem. There is a big difference between a collection of (mostly/largely... trying to be apolitical) people working on a shared chunk of code, and a project producing a specific product. That is a bit of a false dichotomy, but on that spectrum, where as something like Gnome seems to have a project wide vision, schedule, plans; something like the Linux kernel has at least a pretty regular cycle of integrating random factions. Questions about the use of library versions (and major versions Gnome/GTK 3 being the obvious white elephant here) seem to flair up and die out, but no real resolution I can see. Carrying on as normal, not targeting new base libraries, isn't an answer, it is just not doing anything. I don't see a project goal/vision saying that it (we) target long-term platforms (which, while I would disagree with, at least is something tangible to measure against). Of course, compounding this unsolvable question is that there is no release schedule for 2.6 (or 3.0). Maybe all the devs implicitly agree on most everything. I think that that is great. The open source mantra of devs scratching an itch is a bit simplistic... Sure, fixing bug #whatever might be doable; others want, for lack of a better word, belonging, as much as any technical problem solved. I doubt that many potential developers are aware of this; but getting contributions more then just bug #x being squashed... getting new project contributions... really requires a solid project to latch on to. To that end, before you (we?) move to GTK 3, or port Guile to Python, or whatever: Capture and document high level technical and feature goals; prioritize them; mapped to versions, and dates. Time box that (features will slip), but try to get out major feature versions (or versions with major technical changes), say, every 6 months. On Sun, Dec 4, 2011 at 12:35 PM, Graham Leggett minf...@sharp.fm wrote: On 03 Dec 2011, at 11:40 PM, Donald Allen wrote: Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I use gnucash because a) it's been around a long time, and b) because gnucash is likely to be around a long time still. Anyone can start over at any time - that's called a new product - but when people decide to abandon what they have and start over, that's when you lose faith in the project and start to look somewhere else. Sure, new fandangled languages are shiny, but will they still be popular in 5 years? No idea. I am happy to bet that C will be around in 5 years, so investing in the language as unsexy as it might be for me is a good investment. I think gnucash needs a heavy set of refactoring. I'd like to see a proper libgnucash split out as a separate library that I can depend on in other software. I'd like to use a libgnucash library as a basis for a restful service that will allow me to share gnucash with others, like my accountant. But I don't think gnucash needs to be started over. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
This is becoming a good, healthy discussion, with a variety of viewpoints that make for interesting reading. But to those who seem to think that starting over is *always* a bad idea, I'd ask you if you'd like to be running Windows 3.1.14159/MSDOS 19 on your PCs, instead of something based on Windows NT? Or would you like to still be running the original Mac OS on your Macbooks (which would need a Motorola processor or something to deal with the code written in 68k assembly language) and have the whole system fall over when one application goes nuts? It's very difficult to make sensible blanket statements in a complex business like this. Yes, I agree that starting over is a big decision that has to be carefully justified on risk/benefit, cost/benefit grounds. As I said in my original post, I don't know if Gnucash is at that point, because I haven't done the homework. But I do think it's important for people who do know this system well to give the option consideration at a time when attempts are being made to solve major, designed-in problems, and also to take advantage of contemporary tools. /Don ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On Sat, 03 Dec 2011 16:40:07 -0500, Donald Allen wrote: I've been watching with interest the messages flying by from various people that confirm the impression (from just trying to build it) that Gnucash has become a gigantic hairball. John Ralls has been saying a number of things that sound smart (I'll tell you later where to send the check, John) about design errors, problems in the data model, etc., and has embarked upon a re-design. Christian has taken a similar step back with Cutecash. Then there's the whole issue of the use of Scheme. Much as I love the elegance of the language, I doubt that its use is appropriate here, for all the reasons that we've discussed ad nauseum. So I'd like to suggest that perhaps none of the proposed ways-forward are radical enough. I have little to no knowledge of Gnucash internals. The only thing I know about the quality of the design and the code is what I read from the people who are currently doing the real work. But I do have many, many years of experience working and managing projects of similar and greater complexity, and there are times when you just have to cut your losses. Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I don't know that Gnucash is at that point, but I'm suggesting that you give this question very careful consideration, before doing something incremental. Rewriting is a normal process in the design and implementation of quality software. In fact, I consider it essential in maintaining clarity and making reliability possible. But most rewriting is incremental in a well- modularized program. And rewriting that makes a program more modular is often the best kind. In a large program, I often spend half my time rewriting existing code with no change in program behaviour. It's essential to pave the way for later substantive changes. The truth is also that it's very difficult to know how a program should be organized from the start. Only if you've written a number of similar programs before do you have much of a chance of guessing right ab initio. So rewriting and reorganization had better be part of ones' strategy all along. Keep in mind that if you did start over, the current system wouldn't be a total loss. I'm sure there is a lot of value in things like accounting rules that it enforces, and other knowledge embedded in the code. Some of it might be salvageable by lifting parts of the code itself, or at least doing translations. Other cases might involve just transferring knowledge of how to do things and how not to do things. But I say don't throw good money *possibly* (not definitely) after bad without at least considering whether it's time for Gnucash II. Seriously, I've thought of it before deciding to join this project in any role but kibitzer. There's lots of ways I'd like to rewrite it all from scratch (redoing it all in Modula 3, for example). But in my opinion it provides me more return for effort just participating in what's here already. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On Sun, 04 Dec 2011 18:35:08 +0200, Graham Leggett wrote: On 03 Dec 2011, at 11:40 PM, Donald Allen wrote: Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I use gnucash because a) it's been around a long time, and b) because gnucash is likely to be around a long time still. Anyone can start over at any time - that's called a new product - but when people decide to abandon what they have and start over, that's when you lose faith in the project and start to look somewhere else. Sure, new fandangled languages are shiny, but will they still be popular in 5 years? No idea. I am happy to bet that C will be around in 5 years, so investing in the language as unsexy as it might be for me is a good investment. Yeah. C will still be around. Scheme is almost as old, (older if you consider it Lisp) and will be around too. I'd guess Python will too, but I'm not nearly as sure of that. I think gnucash needs a heavy set of refactoring. I'd like to see a proper libgnucash split out as a separate library that I can depend on in other software. I'd like to use a libgnucash library as a basis for a restful service that will allow me to share gnucash with others, like my accountant. But I don't think gnucash needs to be started over. There was once and enterprise-resource system (whatever that is) that comprised around 200,000 lines of C (or was it C++?) code. They decided that for some new functionality they should add a scripting language. They picked Gambit, and implementation of Scheme, as their scripting tool. Now it happens that Gambit is exceptionally compatible with C and C ++, because although it's usually interpreted, it can also be compiled to C or C++ (that's how it's bootstrapped, as it happens). And in the compiled form, it has specific mechanisms to declare and call C functions, include C header files, and so forth. After they started down this path, they discovered other stuff within the program that needed improvement, and found the easiest way to do it was to rewrite in Gambit. Eventually in the course of two years or so, the 200,000 lines of C/C++ had been reduced to about 15,000 lines of Gambit code (or was it 25,000? I forget. I'll look it up if it's really important.) Not only that, but the program ran significantly faster, because of the insights they had into how badly they had been doing things, and because of extensive use of the profiling tools in Gambit. The effect was a complete rewrite. But it was all incremental change. Every bit of it could be seen as improvement over what was there before, and worked in context. Evolutionary change. No. I'm in no hurry to throw Scheme out. Nor am I eager to start a project to rewrite everything in Scheme, or C++ or C# or Mesa, or even one of my favourites, Modula 3. Change what needs to be changed. Change what's ugly and becoming unmaintainable. Prove all things; hold fast to that which is good. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Strategy
I've been watching with interest the messages flying by from various people that confirm the impression (from just trying to build it) that Gnucash has become a gigantic hairball. John Ralls has been saying a number of things that sound smart (I'll tell you later where to send the check, John) about design errors, problems in the data model, etc., and has embarked upon a re-design. Christian has taken a similar step back with Cutecash. Then there's the whole issue of the use of Scheme. Much as I love the elegance of the language, I doubt that its use is appropriate here, for all the reasons that we've discussed ad nauseum. So I'd like to suggest that perhaps none of the proposed ways-forward are radical enough. I have little to no knowledge of Gnucash internals. The only thing I know about the quality of the design and the code is what I read from the people who are currently doing the real work. But I do have many, many years of experience working and managing projects of similar and greater complexity, and there are times when you just have to cut your losses. Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I don't know that Gnucash is at that point, but I'm suggesting that you give this question very careful consideration, before doing something incremental. Keep in mind that if you did start over, the current system wouldn't be a total loss. I'm sure there is a lot of value in things like accounting rules that it enforces, and other knowledge embedded in the code. Some of it might be salvageable by lifting parts of the code itself, or at least doing translations. Other cases might involve just transferring knowledge of how to do things and how not to do things. But I say don't throw good money *possibly* (not definitely) after bad without at least considering whether it's time for Gnucash II. /Don ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On Sat, 2011-12-03 at 16:40 -0500, Donald Allen wrote: The big question is, when is it worth it to cut your losses and start over? I don't have strong opinions, but others do, in the opposite direction: Joel Spolsky says (in the context of Netsape) single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch. and also As a corollary of this axiom, you can ask almost any programmer today about the code they are working on. It's a big hairy mess, they will tell you. I'd like nothing better than to throw it out and start over. There's more in his essay Things You Should Never Do http://www.joelonsoftware.com/articles/fog69.html Ross Boylan ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
