[gmx-developers] Major code reorganization in git coming up

[Erik Lindahl]

Hi,

On Jan 5, 2011, at 4:27 AM, Mark Abraham wrote:

> 
> 
> On 12/31/10, Erik Lindahl <erik at kth.se> wrote:
>> 
>> Hi!
>> 
>> We figured we'd celebrate the upcoming new year with some major changes in the git development branch, consisting primarily of C++ support and a more modular organization of files.
>> This is a gradual process, so this mail is a bit of a warning-message that the master/development branch might have some issues with compilers/build environments the next couple of weeks.
> 
> Wouldn't creating an "unstable" branch be a better approach to a known lengthy period of instability? Now people working off (or fixing) the master branch don't have to change their workflows at all. If bugfix commits or merges from release-4-5-patches happen into master, that's great, and don't affect unstable at all. git branches are lightweight and seem correct to use on almost any excuse.
> 
> Later, once "unstable" has matured a bit, 
> 
> git rebase master
> git checkout master
> git merge unstable
> 
> will create the impression that development on master was seamless. No ugly "merge commits", and the "unstable" branch just quietly goes away afterwards.

That would work fine if master hadn't changed at all in the mean time.

The problem is that in practice there will be lots changes in both branches, with the big architectural changes happening in the "unstable" branch, and we are then forcing the people already doing that work to spend lots of time either on continuously merging in all changes from the master branch (which will be really nasty when both files and the organization is different), or even worse do a huge amount of work for a final single merge when all existing code in master would have to be ported to the architecture new unstable branch first.

So, while I see the problem it is ultimately a question of balance, and we don't want to push even more work on the people already doing the heavy lifting!

Second, I'd like to stress that right now there isn't really any killer functionality in master over release-4-5-patches (well, apart from C++ as of this week :-), so we already have a stable branch that won't move much in the shape of release-4-5-patches!  

If it turns out that the master branch takes longer to stabilize than expected and there are new features we all want to use, we can easily create a 4.6 release based on the current patches branch!

Cheers,

Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20110105/063acbc1/attachment.html>