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 <[email protected]> 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 <[email protected]>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
