If no one else has additional comments should I put this up for a vote? Thanks, james
20.12.2016, 09:15, "James Sirota" <jsir...@apache.org>: > You are correct. This thread is about the release process: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770 > > Does anyone have additional opinions on this? > > 1. Maintenance release would just contain patches to the existing release. > Feature release would contain everything, including patches and new features. > 2. The intention is to rotate the build manager. I did it for the first few > releases, then Casey did it for the next few releasees, someone else will > probably do it for the next few releases, etc... > > Does this seem reasonable to everyone? > > Thanks, > James > > 18.12.2016, 18:15, "Kyle Richardson" <kylerichards...@gmail.com>: >> I think this thread got commingled with the discussion on Coding >> Guidelines. The wiki page on the Release Process is at >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770. >> >> Overall, a really informative document. Thanks for pulling this together. >> Two questions: >> >> 1) I'm a little confused about how the feature release and maintenance >> release branches are going to work. Is the idea that all PRs will be merged >> into master and then also be committed to a FR++ or a MR++ branch (or maybe >> even both)? >> >> 2) Are these steps to be taken by a release manager only or is the >> intention that other committers or PMC members rotate through this >> responsibly? Just curious. I actually kind of like the idea of shuffling >> the duty every now and then to avoid burnout by one person. >> >> -Kyle >> >> On Fri, Dec 16, 2016 at 1:31 PM, James Sirota <jsir...@apache.org> wrote: >> >>> fixed the link and made one addition that a qualified reviewer is a >>> committer or PPMC member >>> >>> 16.12.2016, 11:07, "zeo...@gmail.com" <zeo...@gmail.com>: >>> > Right, I agree. That change looks good to me. >>> > >>> > Looks like the Log4j levels links is broken too. >>> > >>> > For a broken travis - how about "If somehow the tests get into a failing >>> > state on master (such as by a backwards incompatible release of a >>> > dependency) only pull requests intended to rectify master may be merged, >>> > and the removal or disabling of any tests must be +1'd by two >>> reviewers." >>> > >>> > Also, reading through this, should there should be a delineation between >>> a >>> > "reviewer" and somebody who has the ability to vote/+1 a PR? Unless I'm >>> > missing something, right now it looks open to anybody. >>> > >>> > Jon >>> > >>> > On Fri, Dec 16, 2016 at 12:48 PM Nick Allen <n...@nickallen.org> wrote: >>> > >>> > Personally, I don't think it matters who merges the pull request. As >>> long >>> > as you meet the requirements for code review, then anyone should be able >>> to >>> > merge it. In fact, I'd rather have the person who knows most about the >>> > change actually merge it into master to ensure that it goes smoothly. >>> > >>> > On Fri, Dec 16, 2016 at 12:15 PM, James Sirota <jsir...@apache.org> >>> wrote: >>> > >>> >> Jon, for #2 I changed it to: A committer may merge their own pull >>> request, >>> >> but only after a second reviewer has given it a +1. >>> >> >>> >> 16.12.2016, 10:07, "zeo...@gmail.com" <zeo...@gmail.com>: >>> >> > I made some minor changes to the doc - check out the history >>> >> > <https://cwiki.apache.org/confluence/pages/ >>> viewpreviousversions.action? >>> >> pageId=61332235> >>> >> > if you have any concerns. >>> >> > >>> >> > Regarding the larger doc - >>> >> > 1. Not everybody can assign JIRAs to themselves. I recall I had to >>> >> request >>> >> > this access, so that should probably be mentioned. >>> >> > 2. "A committer may never merge their own pull request, a second >>> party >>> >> must >>> >> > merge their changes after it has be properly reviewed." >>> >> > - Is this still true/accurate? I heard both ways. >>> >> > 3. "If somehow the tests get into a failing state on master (such as >>> by >>> > >>> > a >>> >> > backwards incompatible release of a dependency) no pull requests may >>> be >>> >> > merged until this is rectified." >>> >> > - Maybe this should get reassessed using the >>> >> > <https://github.com/apache/incubator-metron/pull/383> most >>> >> > <https://github.com/apache/incubator-metron/pull/381> recent >>> >> > <https://issues.apache.org/jira/browse/METRON-601> build >>> >> > <https://issues.apache.org/jira/browse/METRON-597> failures >>> >> > <https://github.com/apache/incubator-metron/pull/380> as a valuable >>> case >>> >> > study. >>> >> > >>> >> > Jon >>> >> > >>> >> > On Fri, Dec 16, 2016 at 11:38 AM James Sirota <jsir...@apache.org> >>> >> wrote: >>> >> > >>> >> >> I threw together a draft document for our release process. Would you >>> >> want >>> >> >> to add/change/delete anything? >>> >> >> >>> >> >> ------------------- >>> >> >> Thank you, >>> >> >> >>> >> >> James Sirota >>> >> >> PPMC- Apache Metron (Incubating) >>> >> >> jsirota AT apache DOT org >>> >> > -- >>> >> > >>> >> > Jon >>> >> > >>> >> > Sent from my mobile device >>> >> >>> >> ------------------- >>> >> Thank you, >>> >> >>> >> James Sirota >>> >> PPMC- Apache Metron (Incubating) >>> >> jsirota AT apache DOT org >>> > >>> > -- >>> > Nick Allen <n...@nickallen.org> >>> > >>> > -- >>> > >>> > Jon >>> > >>> > Sent from my mobile device >>> >>> ------------------- >>> Thank you, >>> >>> James Sirota >>> PPMC- Apache Metron (Incubating) >>> jsirota AT apache DOT org > > ------------------- > Thank you, > > James Sirota > PPMC- Apache Metron (Incubating) > jsirota AT apache DOT org ------------------- Thank you, James Sirota PPMC- Apache Metron (Incubating) jsirota AT apache DOT org
