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 <so...@cloudera.com> 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 <hol...@pigscanfly.ca> 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 <felixcheun...@hotmail.com >> > 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 <r...@databricks.com> >>> Sent: Friday, September 8, 2017 9:27 AM >>> Subject: Re: 2.1.2 maintenance release? >>> To: Felix Cheung <felixcheun...@hotmail.com>, Holden Karau < >>> hol...@pigscanfly.ca>, Sean Owen <so...@cloudera.com>, dev < >>> dev@spark.apache.org> >>> >>> >>> >>> +1 as well. We should make a few maintenance releases. >>> >>> On Fri, Sep 8, 2017 at 6:46 PM Felix Cheung <felixcheun...@hotmail.com> >>> 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 <so...@cloudera.com> >>>> *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 <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. >>>>> >>>> >>> >>> >> >> >> -- >> Cell : 425-233-8271 >> Twitter: https://twitter.com/holdenkarau >> > -- Cell : 425-233-8271 Twitter: https://twitter.com/holdenkarau
