Re: 2.1.2 maintenance release?
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 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. >
CVE-2017-12612 Unsafe deserialization in Apache Spark launcher API
Severity: Medium Vendor: The Apache Software Foundation Versions Affected: Versions of Apache Spark from 1.6.0 until 2.1.1 Description: In Apache Spark 1.6.0 until 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. It does not affect apps run by spark-submit or spark-shell. The attacker would be able to execute code as the user that ran the Spark application. Users are encouraged to update to version 2.2.0 or later. Mitigation: Update to Apache Spark 2.2.0 or later. Credit: Aditya Sharad, Semmle
Re: 2.1.2 maintenance release?
+1 on both 2.1.2 and 2.2.1 And would try to help and/or wrangle the release if needed. (Note: trying to backport a few changes to branch-2.1 right now) From: Sean Owen Sent: Friday, September 8, 2017 12:05:28 AM To: Holden Karau; dev Subject: Re: 2.1.2 maintenance release? 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 mailto:hol...@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.
Re: 2.1.2 maintenance release?
There's no problem that I'm aware of with a non-PMC member volunteering to be release manager. I was RM for a couple Avro releases without being on the PMC, and this is done regularly in the incubator where IPMC members have binding votes, but someone in the incubating community is the RM. We want to encourage exactly this kind of involvement in order to grow the PMC. This is like how we want everyone---not just committers---to review pull requests or how anyone can vote on a release even if it isn't a binding vote. We never want PMC membership to be a bar that prevents anyone from participating, it just means that someone has demonstrated enough merit that they have the community's trust for votes on releases or new committers. rb On Fri, Sep 8, 2017 at 8:46 AM, Felix Cheung wrote: > +1 on both 2.1.2 and 2.2.1 > > And would try to help and/or wrangle the release if needed. > > (Note: trying to backport a few changes to branch-2.1 right now) > > -- > *From:* Sean Owen > *Sent:* Friday, September 8, 2017 12:05:28 AM > *To:* Holden Karau; dev > *Subject:* Re: 2.1.2 maintenance release? > > 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 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. >> > -- Ryan Blue Software Engineer Netflix
Re: 2.1.2 maintenance release?
+1 as well. We should make a few maintenance releases. On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung wrote: > +1 on both 2.1.2 and 2.2.1 > > And would try to help and/or wrangle the release if needed. > > (Note: trying to backport a few changes to branch-2.1 right now) > > -- > *From:* Sean Owen > *Sent:* Friday, September 8, 2017 12:05:28 AM > *To:* Holden Karau; dev > *Subject:* Re: 2.1.2 maintenance release? > > 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 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. >> >
