2.1.2 maintenance release?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

2.1.2 maintenance release?

Sean Owen
In a separate conversation about bugs and a security issue fixed in 2.1.x and 2.0.x, Marcelo suggested it could be time for a maintenance release. I'm not sure what our stance on 2.0.x is, but 2.1.2 seems like it could be valuable to release.

Thoughts? I believe Holden had expressed interest in even managing the release process, but maybe others are interested as well. That is, this could also be a chance to share that burden and spread release experience around a bit.

Sean
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Dongjoon Hyun-2
+1!

As of today,

For 2.1.2, we have 87 commits. (2.1.1 was released 4 months ago)
For 2.2.1, we have 95 commits. (2.2.0 was released 2 months ago)

Can we have 2.2.1, too?

Bests,
Dongjoon.


On Thu, Sep 7, 2017 at 2:14 AM, Sean Owen <[hidden email]> wrote:
In a separate conversation about bugs and a security issue fixed in 2.1.x and 2.0.x, Marcelo suggested it could be time for a maintenance release. I'm not sure what our stance on 2.0.x is, but 2.1.2 seems like it could be valuable to release.

Thoughts? I believe Holden had expressed interest in even managing the release process, but maybe others are interested as well. That is, this could also be a chance to share that burden and spread release experience around a bit.

Sean

Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Holden Karau
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.

On Thu, Sep 7, 2017 at 1:05 PM, Dongjoon Hyun <[hidden email]> wrote:
+1!

As of today,

For 2.1.2, we have 87 commits. (2.1.1 was released 4 months ago)
For 2.2.1, we have 95 commits. (2.2.0 was released 2 months ago)

Can we have 2.2.1, too?

Bests,
Dongjoon.


On Thu, Sep 7, 2017 at 2:14 AM, Sean Owen <[hidden email]> wrote:
In a separate conversation about bugs and a security issue fixed in 2.1.x and 2.0.x, Marcelo suggested it could be time for a maintenance release. I'm not sure what our stance on 2.0.x is, but 2.1.2 seems like it could be valuable to release.

Thoughts? I believe Holden had expressed interest in even managing the release process, but maybe others are interested as well. That is, this could also be a chance to share that burden and spread release experience around a bit.

Sean




--
Cell : 425-233-8271
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Sean Owen
Let's look at the standard ASF guidance, which actually surprised me when I first read it:


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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Felix Cheung
+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 <[hidden email]>
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:


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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Ryan Blue
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 <[hidden email]> 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 <[hidden email]>
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:


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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

rxin
In reply to this post by Felix Cheung
+1 as well. We should make a few maintenance releases. 

On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung <[hidden email]> 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 <[hidden email]>
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:


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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Felix Cheung
Hi - what are the next steps?
Pending changes are pushed and checked that there is no open JIRA targeting 2.1.2 and 2.2.1

_____________________________
From: Reynold Xin <[hidden email]>
Sent: Friday, September 8, 2017 9:27 AM
Subject: Re: 2.1.2 maintenance release?
To: Felix Cheung <[hidden email]>, Holden Karau <[hidden email]>, Sean Owen <[hidden email]>, dev <[hidden email]>


+1 as well. We should make a few maintenance releases. 

On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung <[hidden email]> 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 <[hidden email]>
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:


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 <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Holden Karau
So I think the consensus is that their is interest in having a few maintenance releases. I'm happy to act as the RM. I think the next step is seeing who the PMC wants as the RM for these (and if people are OK with me I'll start updating my self on the docs, open JIRAs, and relevant Jenkins jobs for packaging).

On Sun, Sep 10, 2017 at 11:31 PM, Felix Cheung <[hidden email]> wrote:
Hi - what are the next steps?
Pending changes are pushed and checked that there is no open JIRA targeting 2.1.2 and 2.2.1

_____________________________
From: Reynold Xin <[hidden email]>
Sent: Friday, September 8, 2017 9:27 AM
Subject: Re: 2.1.2 maintenance release?
To: Felix Cheung <[hidden email]>, Holden Karau <[hidden email]>, Sean Owen <[hidden email]>, dev <[hidden email]>



+1 as well. We should make a few maintenance releases. 

On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung <[hidden email]> 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 <[hidden email]>
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:


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 <[hidden email]> 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.





--
Cell : 425-233-8271
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Sean Owen
I think you could just dive in to the steps at http://spark.apache.org/release-process.html and see how far you get before you need assistance to execute steps like tagging and publishing artifacts. 

I think a secondary goal of this process is to update and expand those release documents, as a fresh set of eyes inevitably sees points that need clarification and that aren't obvious to people who haven't run this process before.

Some of this is already done: no need for a new branch, all 2.1.2 issues are resolved, branch already set to 2.1.2-SNAPSHOT. (Here's an example: the docs don't note that the spark-build-info script auto-updates the string that is used by the Spark REPL string.)

The first area where you might need help or additional access is the bit about Jenkins jobs that cut release candidates automatically. It'd be good to add any notes about how that works here, too, for posterity.

Which jobs are these and who could help set one up to cut 2.1.2 RC1?


On Mon, Sep 11, 2017 at 7:41 AM Holden Karau <[hidden email]> wrote:
So I think the consensus is that their is interest in having a few maintenance releases. I'm happy to act as the RM. I think the next step is seeing who the PMC wants as the RM for these (and if people are OK with me I'll start updating my self on the docs, open JIRAs, and relevant Jenkins jobs for packaging).

On Sun, Sep 10, 2017 at 11:31 PM, Felix Cheung <[hidden email]> wrote:
Hi - what are the next steps?
Pending changes are pushed and checked that there is no open JIRA targeting 2.1.2 and 2.2.1

_____________________________
From: Reynold Xin <[hidden email]>
Sent: Friday, September 8, 2017 9:27 AM
Subject: Re: 2.1.2 maintenance release?
To: Felix Cheung <[hidden email]>, Holden Karau <[hidden email]>, Sean Owen <[hidden email]>, dev <[hidden email]>



+1 as well. We should make a few maintenance releases. 

On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung <[hidden email]> 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 <[hidden email]>
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:


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 <[hidden email]> 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.





--
Cell : 425-233-8271
Reply | Threaded
Open this post in threaded view
|

Re: 2.1.2 maintenance release?

Holden Karau
Sounds good. I have a little more experience with the Jenkins jobs packaging from helping debug the Python packaging issues so I'll get started and look at updating the docs as I go until I get stuck.

On Tue, Sep 12, 2017 at 2:29 AM Sean Owen <[hidden email]> wrote:
I think you could just dive in to the steps at http://spark.apache.org/release-process.html and see how far you get before you need assistance to execute steps like tagging and publishing artifacts. 

I think a secondary goal of this process is to update and expand those release documents, as a fresh set of eyes inevitably sees points that need clarification and that aren't obvious to people who haven't run this process before.

Some of this is already done: no need for a new branch, all 2.1.2 issues are resolved, branch already set to 2.1.2-SNAPSHOT. (Here's an example: the docs don't note that the spark-build-info script auto-updates the string that is used by the Spark REPL string.)

The first area where you might need help or additional access is the bit about Jenkins jobs that cut release candidates automatically. It'd be good to add any notes about how that works here, too, for posterity.

Which jobs are these and who could help set one up to cut 2.1.2 RC1?


On Mon, Sep 11, 2017 at 7:41 AM Holden Karau <[hidden email]> wrote:
So I think the consensus is that their is interest in having a few maintenance releases. I'm happy to act as the RM. I think the next step is seeing who the PMC wants as the RM for these (and if people are OK with me I'll start updating my self on the docs, open JIRAs, and relevant Jenkins jobs for packaging).

On Sun, Sep 10, 2017 at 11:31 PM, Felix Cheung <[hidden email]> wrote:
Hi - what are the next steps?
Pending changes are pushed and checked that there is no open JIRA targeting 2.1.2 and 2.2.1

_____________________________
From: Reynold Xin <[hidden email]>
Sent: Friday, September 8, 2017 9:27 AM
Subject: Re: 2.1.2 maintenance release?
To: Felix Cheung <[hidden email]>, Holden Karau <[hidden email]>, Sean Owen <[hidden email]>, dev <[hidden email]>



+1 as well. We should make a few maintenance releases. 

On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung <[hidden email]> 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 <[hidden email]>
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:


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 <[hidden email]> 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.





--
Cell : 425-233-8271
--
Cell : 425-233-8271