On Sat, May 25, 2013 at 10:52:34AM -0400, Outback Dingo wrote: > On Sat, May 25, 2013 at 10:33 AM, Chip Childers > <chip.child...@sungard.com>wrote: > > > On May 25, 2013, at 10:16 AM, Sebastien Goasguen <run...@gmail.com> wrote: > > > > > > > > On May 25, 2013, at 10:08 AM, Outback Dingo <outbackdi...@gmail.com> > > wrote: > > > > > >> On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen <run...@gmail.com > > >wrote: > > >> > > >>> Hi folks, > > >>> > > >>> Some time back I offered to be RM for 4.1.x , since then I took on the > > >>> GSoC effort and won't have time to be the RM. > > >>> > > >>> Therefore the position is up for grabs. > > >>> > > >>> Any takers ? > > >> > > >> can we get a brief description of the responsibilities? I just might be > > >> interested > > > > > > You would be responsible to get the 4.1.x releases out the door. Keep > > track of the JIRA bugs that need to be applied to the 4.1 branch, > > cherry-pick them, do some minimal testing and conflict resolution. Then > > prepare the source artifacts, signature, release notes. And finally start > > the [VOTE] threads. > > > > > > Basically what Joe has been doing for 4.0.x, am I sure he can elaborate > > and my one sentence description. > > > > > > I am sure, Chip, Joe, myself and others would help you out to get in the > > groove. > > > > > > -Sebastien > > > > The only requirement is that the RM needs to be a committer for the > > technical aspects of the work. However, we might be able to work > > something out if a non committer wanted to do this. > > > > From my opinion on being an RM, I dont believe the need to be a commiter > should exist.
It does for the technical bits - actually doing commits to the repo, access to the release distro area, the right to call a release VOTE, etc... > However I have no issues being a commiter, Im not inclined to do major > works, until I shore > up the work Ive done, which is very XCP specific. Sorry - just to be clear here. I'm not suggesting that someone offering to help with the release management would immediately be given commit rights. > In my opinion, an RM > should have some > autonomy in management. An RM within this community is a facilitator for the rest of the community, as we work toward a shared goal: to do a release. > Ive run R&D shops for a decade, We always > designated a non-dev > type to manage the release, to remove the politics from the development and > build process. > And all senior development leaders would have to sign off on a release as > being ready from > their code perspective. For us it helped our developers take ownership of > issues as they arose. > Aside from that Id like to contribute, in light of responsibilities I do > have the experience. and well > some of the CS people know me and what Ive been up. :) Ill throw my hat in > the ring. Id be more > then happy to help. Glad you are willing to help! I do think this would be easier with a volunteer to be the official RM that's already a committer. That being said, perhaps you want to help with identifying bugs that are fixed in master, and can easily be brought into 4.1 for an eventual 4.1.1 release? That's actually the harder part of the maintenance release work. -chip
