cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Outback Dingo <outbackdi...@gmail.com>
Subject Re: 4.1 release manager
Date Sun, 26 May 2013 17:00:35 GMT
On Sun, May 26, 2013 at 10:24 AM, Chip Childers
<chip.childers@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.childers@sungard.com>wrote:
> >
> > > On May 25, 2013, at 10:16 AM, Sebastien Goasguen <runseb@gmail.com>
> wrote:
> > >
> > > >
> > > > On May 25, 2013, at 10:08 AM, Outback Dingo <outbackdingo@gmail.com>
> > > wrote:
> > > >
> > > >> On Sat, May 25, 2013 at 10:06 AM, Sebastien Goasguen <
> runseb@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message