spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <so...@cloudera.com>
Subject Re: 2.1.2 maintenance release?
Date Fri, 08 Sep 2017 07:05:28 GMT
Let's look at the standard ASF guidance, which actually surprised me when I
first read it:

https://www.apache.org/foundation/voting.html

VOTES ON PACKAGE RELEASES
Votes on whether a package is ready to be released use majority approval --
i.e. at least three PMC members must vote affirmatively for release, and
there must be more positive than negative votes. Releases may not be
vetoed. Generally the community will cancel the release vote if anyone
identifies serious problems, but in most cases the ultimate decision, lies
with the individual serving as release manager. The specifics of the
process may vary from project to project, but the 'minimum quorum of three
+1 votes' rule is universal.


PMC votes on it, but no vetoes allowed, and the release manager makes the
final call. Not your usual vote! doesn't say the release manager has to be
part of the PMC though it's the role with most decision power. In practice
I can't imagine it's a problem, but we could also just have someone on the
PMC technically be the release manager even as someone else is really
operating the release.

The goal is, really, to be able to put out maintenance releases with
important fixes. Secondly, to ramp up one or more additional people to
perform the release steps. Maintenance releases ought to be the least
controversial releases to decide.

Thoughts on kicking off a release for 2.1.2 to see how it goes?

Although someone can just start following the steps, I think it will
certainly require some help from Michael, who's run the last release, to
clarify parts of the process or possibly provide an essential credential to
upload artifacts.


On Thu, Sep 7, 2017 at 11:59 PM Holden Karau <holden@pigscanfly.ca> wrote:

> I'd be happy to manage the 2.1.2 maintenance release (and 2.2.1 after
> that) if people are ok with a committer / me running the release process
> rather than a full PMC member.
>

Mime
View raw message