We will soon be tagging a 1.0beta release and publishing the tarball for the release. Something I don't think we've talked about much is how development will proceed on git branches after that release. I'd like to propose to propose a plan of action for team consideration, referring to this blog post David sent out earlier for reference: http://nvie.com/git-model Once we do the 1.0beta release, I propose we do the following: * Stop actively developing on master. Instead, a 1.0 release manager should be chosen to pick when master should updated with a pointer to the improved release branch. (I'd expect this would happen at official release candidate stages, and then the final 1.0 release) * Continue active development of features not meant for 1.0 on a new branch. We could call it 'develop' like in the blog post but out of svn nostalgia and because I think it's weird to give a branch a name that's a verb I'd be +1 calling it "trunk" * 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. If the above proposal is accepted, then I would nominate David as 1.0 release manager. -- Sebastian Benthall OpenGeo - http://opengeo.org
Ok, based discussions, here is an amended proposal. Comments + votes much appreciated! ------------------------------------------------------------------------------ Once we do the 1.0beta release, I propose we do the following: * Stop actively developing on master. Instead, master should be periodically updated with a pointer to the improved release branch. (I'd expect this would happen at official release candidate stages, and then the final 1.0 release) * Continue active development of features not meant for 1.0 on a new branch (code name: 'community development branch') * Make a branch, release-branch-1.0, to which we only commit bug fixes (pulled from community development branch) We should also elect a release manager. The release manager should have the following duties: * Take responsibility for bringing commits from the community development branch to the release branch. The release manager can opt to do it themselves, or can ask for community assistance, at their discretion. * Make release announcements to the mailing list, including lists of bugs fixed. * Tagging the master branch with the release and release candidates. * Building the pre-release tarball, testing it, and putting it somewhere accessible. * Determining if any other release processes are necessary and bringing them up on the list. * Documenting their steps so that somebody else can be release manager later. --------------------------------------------------------------- If the above proposal passes, then it raises the following items: --------------------------------------------------------------- SUB PROPOSAL (A): What should we name the community development branch? Ballot: [ ] integration [ ] unstable [ ] trunk [ ] Other: ____________________ (write in candidate) --------------------------------------------------------------- SUB PROPOSAL (B): Who should be the release manager? [ ] David [ ] Seb [ ] David and Seb settle the question with dueling water pistols at sunset on the OpenGeo roof deck. [ ] Other: __________________ (write in candidate) --------------------------------------------------------------- On Thu, Jul 29, 2010 at 11:25 AM, Sebastian Benthall <seb@opengeo.org>wrote: > We will soon be tagging a 1.0beta release and publishing the tarball for > the release. > > Something I don't think we've talked about much is how development will > proceed on git branches after that release. > > I'd like to propose to propose a plan of action for team consideration, > referring to this blog post David sent out earlier for reference: > http://nvie.com/git-model > > Once we do the 1.0beta release, I propose we do the following: > > * Stop actively developing on master. Instead, a 1.0 release manager > should be chosen to pick when master should updated with a pointer to the > improved release branch. (I'd expect this would happen at official release > candidate stages, and then the final 1.0 release) > > * Continue active development of features not meant for 1.0 on a new > branch. We could call it 'develop' like in the blog post but out of svn > nostalgia and because I think it's weird to give a branch a name that's a > verb I'd be +1 calling it "trunk" > > * 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. > > If the above proposal is accepted, then I would nominate David as 1.0 > release manager. > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > > -- Sebastian Benthall OpenGeo - http://opengeo.org
Ok, no on-line responses to this. But David and I talked and we agreed that I should take the release manager role this time around. So I'll be doing these steps today. On Tue, Aug 3, 2010 at 12:05 PM, Sebastian Benthall <seb@opengeo.org> wrote: > Ok, based discussions, here is an amended proposal. Comments + votes much > appreciated! > > > ------------------------------------------------------------------------------ > > Once we do the 1.0beta release, I propose we do the following: > > * Stop actively developing on master. Instead, master should be > periodically updated with a pointer to the improved release branch. (I'd > expect this would happen at official release candidate stages, and then > the final 1.0 release) > > * Continue active development of features not meant for 1.0 on a new > branch (code name: 'community development branch') > > * Make a branch, release-branch-1.0, to which we only commit bug fixes > (pulled from community development branch) > > > We should also elect a release manager. The release manager should have > the following duties: > > * Take responsibility for bringing commits from the community development > branch to the release branch. The release manager can opt to do it > themselves, or can ask for community assistance, at their discretion. > > * Make release announcements to the mailing list, including lists of bugs > fixed. > > * Tagging the master branch with the release and release candidates. > > * Building the pre-release tarball, testing it, and putting it somewhere > accessible. > > * Determining if any other release processes are necessary and bringing > them up on the list. > > * Documenting their steps so that somebody else can be release manager > later. > > --------------------------------------------------------------- > > > If the above proposal passes, then it raises the following items: > > --------------------------------------------------------------- > > SUB PROPOSAL (A): What should we name the community development branch? > > Ballot: > > [ ] integration > [ ] unstable > [ ] trunk > [ ] Other: ____________________ (write in candidate) > > --------------------------------------------------------------- > > SUB PROPOSAL (B): Who should be the release manager? > > [ ] David > [ ] Seb > [ ] David and Seb settle the question with dueling water pistols at > sunset on the OpenGeo roof deck. > [ ] Other: __________________ (write in candidate) > > --------------------------------------------------------------- > > > > On Thu, Jul 29, 2010 at 11:25 AM, Sebastian Benthall <seb@opengeo.org>wrote: > >> We will soon be tagging a 1.0beta release and publishing the tarball for >> the release. >> >> Something I don't think we've talked about much is how development will >> proceed on git branches after that release. >> >> I'd like to propose to propose a plan of action for team consideration, >> referring to this blog post David sent out earlier for reference: >> http://nvie.com/git-model >> >> Once we do the 1.0beta release, I propose we do the following: >> >> * Stop actively developing on master. Instead, a 1.0 release manager >> should be chosen to pick when master should updated with a pointer to the >> improved release branch. (I'd expect this would happen at official release >> candidate stages, and then the final 1.0 release) >> >> * Continue active development of features not meant for 1.0 on a new >> branch. We could call it 'develop' like in the blog post but out of svn >> nostalgia and because I think it's weird to give a branch a name that's a >> verb I'd be +1 calling it "trunk" >> >> * 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. >> >> If the above proposal is accepted, then I would nominate David as 1.0 >> release manager. >> >> -- >> Sebastian Benthall >> OpenGeo - http://opengeo.org >> >> > > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > > -- Sebastian Benthall OpenGeo - http://opengeo.org
On 07/29/2010 11:25 AM, Sebastian Benthall wrote: > We will soon be tagging a 1.0beta release and publishing the tarball > for the release. > > Something I don't think we've talked about much is how development > will proceed on git branches after that release. > > I'd like to propose to propose a plan of action for team > consideration, referring to this blog post David sent out earlier for > reference: > http://nvie.com/git-model > > Once we do the 1.0beta release, I propose we do the following: > > * Stop actively developing on master. Instead, a 1.0 release > manager should be chosen to pick when master should updated with a > pointer to the improved release branch. (I'd expect this would happen > at official release candidate stages, and then the final 1.0 release) > > * Continue active development of features not meant for 1.0 on a new > branch. We could call it 'develop' like in the blog post but out of > svn nostalgia and because I think it's weird to give a branch a name > that's a verb I'd be +1 calling it "trunk" 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". > * 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? > If the above proposal is accepted, then I would nominate David as 1.0 > release manager. > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org >
> > 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