cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Higgins <br...@bryanhiggins.net>
Subject Re: Release Managers
Date Thu, 13 Mar 2014 17:34:37 GMT
+1, I'll throw my hat in the ring as well


On Thu, Mar 13, 2014 at 1:13 PM, Steven Gill <stevengill97@gmail.com> wrote:

> I'm obviously a +1 and highly support this idea.
> On Mar 13, 2014 9:57 AM, "Naik, Archana" <naika@lab126.com> wrote:
>
> > +1 I like the idea too. I have never done a release and don't mind being
> a
> > guinea pig here҆ :)
> >
> > Archana
> >
> > On 3/13/14 9:44 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
> >
> > >+1, like the idea of putting your name into a hat.
> > >
> > >How about "coaching" the first time someone does a release?  Do we
> prefer
> > >to let the docs stand for themselves?
> > >
> > >-Michal
> > >
> > >
> > >On Thu, Mar 13, 2014 at 11:13 AM, Andrew Grieve
> > ><agrieve@chromium.org>wrote:
> > >
> > >> I'd previously brought up the idea of "Release Masters", and now after
> > >>the
> > >> recent highlight of our release process by other Apache project
> members,
> > >> I've learned that they are common, and are actually called "Release
> > >> Managers".
> > >>
> > >> Their role, in a nutshell, is to take ownership of a release (either
> > >> through delegation, or by doing it themselves).
> > >>
> > >> It's generally not a glorious job, so it would be great if we could
> do a
> > >> bit of a rotation on it:
> > >> - a rotation for tools,
> > >> - a rotation for plugins,
> > >> - a rotation for platforms release.
> > >>
> > >> For tools & plugins, the responsibility is a bit better defined I
> think
> > >>-
> > >> they are responsible for going through the steps in the release
> process.
> > >>
> > >> For platform releases, the release manager wouldn't necessarily be
> > >> responsible for individual platforms, but rather for things like docs,
> > >> website, dist/, and for poking people.
> > >>
> > >>
> > >> As for a rotation, one thought is to write down the names of those
> > >>willing
> > >> in the actual release steps .md files, and then they can plan out how
> to
> > >> schedule themselves from there.
> > >>
> > >> How does this sound?
> > >>
> >
> >
>

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