On Sun, May 26, 2013 at 10:24 AM, Chip Childers <chip.child...@sungard.com>wrote:
> 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... > well, yes if the responsibilities include modification of code, you would require access > > > 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. > Which is understandable, committers need time to be vetted and work reviewed, of which I have been working for months and object storage design specific to CS, as a project of my own which hopefully, one day will see light of day in CS and a plugin > > > 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 >
