Hi Adam, > I don't have any experience using git but from what I've read it sounds like > it could help our community.
I don't have a lot of hands-on experience as well. That being said, it won't stop me from commenting on git vs. svn :-) Git is said to be an improved version of svn, and in my opinion, it *does* simplify certain tasks, mostly on the technical level, though. The problem that we are facing will however *not* go away simply by switching to git. The thinking behind this is: Assuming that we more ore less follow the model of developing new features in branches, we'll always get to the point where somebody will need to do the merging, no matter which source code management system we use. As long as this merging is not done correctly, we keep running into the problems that you describe, and git won't help us here, as it is - to my knowledge - optimized for a central release manager, somebody we don't have and won't have anytime soon. Instead, the little example that Greg gave yesterday seems to be a viable solution: Changes are merged to release branches (in case of fixes) and trunk by the developer(s) and will then be tested by the community. And here is the critical part: if the merge is found to destabilize the build, there should be no question about whether the merge needs to be rolled back. After a quick heads-up to the developer and a grace period without a fix, everybody should have the right and the obligation to roll the merge back, as the code is simply not stable. > In an ideal world, our release process should not involve 10+ release > candidates and a QA process spread over many months, but since we don't live > in this world should we consider moving to git? The main issue is that we > can't/shouldn't put a code freeze on trunk as we fix bugs on our 1.1.x and > 1.2.x branches, but merging fixes back into trunk has become a challenge. As > time passes our branches and trunk grow significantly out of sync. There are > fixes in 1.1.x that had never made their way back into trunk, and it is > likely that additional fixes in other branches will fall through the cracks > as we proceed. The code freeze issue has been discussed many times and I think that we found a solution for it when discussing releases in Chicago. There we said that we would choose an arbitrary and well-communicated date to start the release cycle, then identify bugs and blockers and eliminate new features from the build that don't work and are not being fixed between two adjacent release candidates (again with well-defined timespans between those release candidates). Like this, no code freeze needs to happen and releases will get out the door in a timely manner. > This is by no means a criticism, as many open source projects continually > struggle with these same issues. I don't necessarily think we should go this > route as it is difficult to shift developer practices and apply an > administrative process around a new repo approach. I guess this is more of a > request for proposals rather than an actual proposal because I haven't used > git and can't make a confident recommendation/comparison. I've pinged some > of my colleagues from Sakai OAE in case they want to chime in, as they had > decided to move from svn to git. Thoughts/Comments are welcome by all. I share your concerns about changing the code management system right now, as we are still in the process of getting organized in our new governing model. In addition, to my knowledge there is a one person in Sakai OAE that is managing the sources and hand-picking merges to "trunk". As long as there is no such resource on the Matterhorn project, I can't see but minor advantages in a switch to git at the current moment, and instead I propose to establish and strictly follow the releases process outlined above and proposed at Chicago. Tobias _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
