Re: [DISCUSS] Release Process

Maybe this can be scripted as well On January 17, 2017 at 15:34:10, Casey Stella (ceste...@gmail.com) wrote: Larry, Thanks for the info. In that case, then the following passage: > Now, we must grab the release candidate binary from the github releases > page

Re: [DISCUSS] Release Process

Ok. just made the last of the changes. Putting it up for a vote... Thanks for your comments, guys. James 17.01.2017, 15:17, "Matt Foley" : > Sure, sounds fine to me. > > On 1/17/17, 1:03 PM, "Casey Stella" wrote: > > We haven't actually bitten off

Re: [DISCUSS] Release Process

Sure, sounds fine to me. On 1/17/17, 1:03 PM, "Casey Stella" wrote: We haven't actually bitten off the "publishing maven artifacts" just yet, so I can't say that I have a good idea in my head what the detailed steps are going to be. If we think that it's a good

Re: [DISCUSS] Release Process

That looks great, Casey! Gonna save this off for addressing the same in Knox if needed. :) On Tue, Jan 17, 2017 at 3:33 PM, Casey Stella wrote: > Larry, > > Thanks for the info. In that case, then the following passage: > > > Now, we must grab the release candidate binary

Re: [DISCUSS] Release Process

It is technically a violation of apache release policy to build releases in such a way [1]: MUST RELEASES BE BUILT ON HARDWARE OWNED AND CONTROLLED BY THE COMMITTER? Strictly speaking, releases must be verified

Re: [DISCUSS] Release Process

Speaking as the current release manager, it's pretty obvious when you've done something wrong and as part of the vote in incubator general the collateral is pretty heavily scrutinized. On Mon, Jan 16, 2017 at 3:52 PM, Otto Fowler wrote: > If you are the person

Re: [DISCUSS] Release Process

Hey Matt, Github actually constructs the tarball for us using git archive (for every tag, for that matter). We don't explicitly push any tarball to github. The reason why we pull the tarball from github directly is that we ship a .gitattributes to define what gets put in the tarball. (we don't

Re: [DISCUSS] Release Process

Overall, a great contribution. I suspect that as the next couple Release Managers go thru it, they’ll find various glitches to clean up, but that’s fine. Bravo especially for the last couple paragraphs (Ensuring Consistency between Feature and Maint Releases), which are very good. One major

Re: [DISCUSS] Release Process

If you are the person responsible for doing these steps, who double checks your work? Or reviews? Is there such a person? Should that be called out? On January 16, 2017 at 15:04:36, James Sirota (jsir...@apache.org) wrote: If no one has additional comments on this document i'll go ahead and

Re: [DISCUSS] Release Process

If no one has additional comments on this document i'll go ahead and put it up for a vote... https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770 10.01.2017, 12:50, "James Sirota" : > Hi Larry, > > Thanks for the comments. I beefed up the technical

Re: [DISCUSS] Release Process

Hi Larry, Thanks for the comments. I beefed up the technical section. How does this look? https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770 0.[FR++].0Metron Release Types There are two types of Metron releases: Feature Release (FR) - this is a release that has a

Re: [DISCUSS] Release Process

Hi James - This looks pretty good! A couple quick comments: * for step 10 - the KEYS file appears to be provided for each release as part of the release candidate itself. While I do see some projects do this, I think it is actually best practice to have a single KEYS file in a well known place

Re: [DISCUSS] Release Process

Hi James, is there a formatted version of this somewhere we can look at? Thanks, --Matt On 1/4/17, 1:53 PM, "James Sirota" wrote: Revised as per additional comments. Are there more comments? Or can we put this up for a vote? Release Process [DRAFT] Skip

Re: [DISCUSS] Release Process

Revised as per additional comments. Are there more comments? Or can we put this up for a vote? Release Process [DRAFT] Skip to end of metadata Created by James Sirota, last modified just a moment ago Go to start of metadata Metron Release Types There are two types of Metron releases: Feature

Re: [DISCUSS] Release Process

1. Agree. Being able to maintain the previous release train, with only critical or important bug fixes and security fixes (generally not new features) for users who are averse to frequent large changes, is very important for production use. They get stability, while the mainline code proceeds

Re: [DISCUSS] Release Process

If no one else has additional comments should I put this up for a vote? Thanks, james 20.12.2016, 09:15, "James Sirota" : > You are correct. This thread is about the release process: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=66854770 > > Does anyone

Re: [DISCUSS] Release Process

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

Re: [DISCUSS] Release Process

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

Re: [DISCUSS] Release Process

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" : > 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

Re: [DISCUSS] Release Process

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

Re: [DISCUSS] Release Process

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

Re: [DISCUSS] Release Process

Yeah, that's a good catch. I merge my own PRs all the time. ;) On Fri, Dec 16, 2016 at 12:15 PM, James Sirota 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,

Re: [DISCUSS] Release Process

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" : > I made some minor changes to the doc - check out the history >

Re: [DISCUSS] Release Process

I made some minor changes to the doc - check out the history 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