> > I don't think it's a great idea to use Subversion terminology in git. "git > revert" and "svn revert" are very different things, and in general trying to > think of git as "subversion with extra knobs" is a recipe for shooting > yourself in the foot. In this case, 'trunk' and 'master' are just > conventions so there's less potential for damage. But I'd still go for > "integration" (it's the branch where we are bringing all the new features > together) or "unstable" or something rather than "trunk". >
Ok, I'll correct my vote to +0 for "trunk", which to me is just a nice way to denote a canonically central branch. My nostalgia in this case was for a simple way to refer to that branch (as opposed to 'master at github/geonode") See http://en.wikipedia.org/wiki/Trunk_(software) > * Make a branch, release-branch-1.0, to which we only commit bug fixes > (pulled from trunk) > > In addition to the above proposal, I'd be +0 on the release manager being > the person responsible for bringing commits from trunk into the release > branch. I think that should be up to the release manager though. > > What does the release manager do if he is not playing gatekeeper for the > release branch? > Good question. Perhaps nothing. Hadn't thought that through beyond updating master and possibly gatekeeping. I was hoping that others with more experience with open source releases would chime in with amendments to the proposal as appropriate. This is the description of the OpenLayers release manager from their wiki, which I just looked up now: http://trac.openlayers.org/wiki/ReleaseManager I think some subset of those roles are definitely applicable * release announcements * calling for the PSC), but it's obviously complicated by the fact that our scope, timeline and to some extent our roles are set organizationally Since I'll be asking estimates, projecting the release date, and confirming the scope with the client anyway, I suppose I should volunteer to be release manager myself. But I nominated you because I think your breadth of understanding of the stack and prodigious git fu make you best qualified to be gate-keeper. As a tangent, just to be open about this: this is another case where personally I'm trying to navigate between the our organizational expectations/responsibilities, the development of our nascent open source community, and the technical needs of the software development and release. I see this is a good time grow community processes and establish precedent. And I think that the community decisions we've been making are all of greater legitimacy *because* they are community decisions. But if as a team you think it would be more efficient if I were more decisive (in a managerial role) I can do that too. I'm honestly not sure what the best way for me to act is, and welcome advice about it. -- Sebastian Benthall OpenGeo - http://opengeo.org
