From a user’s perspective, I think it’s important that we can identify a stable version (release?) and the development/feature branches or trunk. We just got our GeoNode installation and are currently thinking about a setup with 2 GeoNode versions here:
- production: will pull changes from our staging/dev version (tested and approved) and ideally from a master stable version from github (e.g. hotfixes, like the linked article below mentions) - staging/dev: will pull changes from trunk, feature branches, etc. and other peers; try and test new features, doesn’t really matter if it breaks. We’ve forked GeoNode on github for our installation for now, that’s the place we’re working off now and where all our changes are going (customization, configuration and templating work mainly). Christian From: [email protected] [mailto:[email protected]] On Behalf Of Sebastian Benthall Sent: Thursday, June 24, 2010 12:31 PM To: [email protected] Subject: Re: [geonode] GeoNode git management Regarding feature branches... In most of the open source projects I've worked on with a central repository there seems to be a system of patch review so that all contributions get an extra pair of eyes. We deliberately opted *out* of that for these early stages of development, because we thought that would slow us down. I think that was a good decision. But I think that there may be potential in using git to find a middle ground that ties the review procedure more closely to the version control system, and less to the issue tracking system. That's vague, I know. Really, I'm just very curious to see what we come up with in terms of development process. I hope this is an area that we all feel confident expressing our opinions on, because we have a lot of expertise on open source process and discipline among us, but how to adapt those processes and discipline to git is still an open question for the world at this point. On Wed, Jun 23, 2010 at 5:25 PM, David Winslow <[email protected]<mailto:[email protected]>> wrote: Hey guys, now that Andreas has at least familiarized himself with git enough to get some changes into the new github repository, it seems like a good time to start discussing how to manage our branches. In SVN there is a pretty common structure: trunk - crazy new stuff gets added here branches - when you need to do development with a bit of protection from the wild firehose that is trunk, you copy trunk into a subfolder here. copies are cheap in svn, do this as much as you like. pulling in changes from trunk is doable, but kind of a pain tags - when you have an interesting version of trunk or a branch you copy it here with a descriptive name and then agree never to change it again. In git there are lots of possibilities. Right now we are kind of ignoring them and just have everyone pushing changes to the master branch as they make them. We could use branches really heavily, we could even give each developer his own repository, whatever, git will mostly keep track of stuff as long as you don't edit history after publishing it. I'm not necessarily opposed to the "firehose" approach, but my personal preferences tend toward using "feature branches" with a bit heavier review before updating master, and trying to keep the master branch in the public repository "ready to release," or at least not totally broken. Here's an article on a really structured git approach that I thought was pretty interesting: http://nvie.com/git-model . It is probably on the extreme end of isolating work into separate branches. What do you all think? -- David Winslow OpenGeo - http://opengeo.org/ -- Sebastian Benthall OpenGeo - http://opengeo.org ________________________________ Please be advised that the Massachusetts Secretary of State considers e-mail to be a public record, and therefore subject to the Massachusetts Public Records Law, M.G.L. c. 66 § 10.
