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
