Are there any other requirements around the release build machine? Does it require anti-virus or anything like that?
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 (https://github.com/apache/incubator-metron/releases). In our case, > for RC1, that would be > https://github.com/apache/incubator-metron/archive/apache-metron-0.[FR++].0-rc1-incubating.tar.gz We > will refer to this as the release candidate tarball. Should be replaced with: > Now we must create the release candidate tarball. From the apache repo, > you should run: > git archive --prefix=apache-metron-0.[FR++].0-rc1-incubating/ > apache-metron-0.[FR++].0-rc1-incubating | gzip > > apache-metron-0.[FR++].0-rc-incubating.tar.gz We will refer to this as the > release candidate tarball. On Tue, Jan 17, 2017 at 3:20 PM, larry mccay <lmc...@apache.org> wrote: > 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? > <http://www.apache.org/dev/release.html#owned-controlled-hardware> > > Strictly speaking, releases must be verified > <https://svn.apache.org/repos/private/committers/tools/ > releases/compare_dirs.pl> > on > hardware owned and controlled by the committer. That means hardware the > committer has physical possession and control of and exclusively full > administrative/superuser access to. That's because only such hardware is > qualified to hold a PGP private key, and the release should be verified on > the machine the private key lives on or on a machine as trusted as that. > > Practically speaking, when a release consists of anything beyond an archive > (e.g., tarball or zip file) of a source control tag, the only practical way > to validate that archive is to build it locally; manually inspecting > generated files (especially binary files) is not feasible. So, basically, > "Yes". > > *Note: This answer refers to the process used to produce a release artifact > from a source control tag. It does not refer to testing that artifact for > technical quality.* > > > Knox is still using the archive from a jenkins build and is also out of > compliance. > > We will need to eventually change this approach as well. > > The threat is that someone could compromise such a remote system in a way > that adds additional classes or alters the code in someway that the project > will then be propagating this compromised binary under the Apache brand. > > > 1. http://www.apache.org/dev/release.html#owned-controlled-hardware > > On Tue, Jan 17, 2017 at 2:43 PM, Casey Stella <ceste...@gmail.com> wrote: > > > 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 ship the > > site for instance). This was just easier to describe than to walk > through > > using git archive. I don't think it's hurting anything necessarily, but > I > > might be wrong. > > > > Regarding Step 7, that can be made explicit, but the link is part of the > > VOTE template. > > > > Regarding maintenance releases, 1 and 2 may be skipped for a maintenance > > release, but the rest really should be followed. It's a release and must > > abide by apache requirements, I think. Maybe the mentors could chime in, > > though. > > > > Regarding Security break-fix, I'm not sure. Perhaps the mentors can > chime > > in? > > > > Casey > > > > On Mon, Jan 16, 2017 at 4:05 PM, Matt Foley <ma...@apache.org> wrote: > > > > > 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 issue: Step 4 says: > > > >> Now, we must grab the release candidate binary from the github > > releases > > > page (https://github.com/apache/incubator-metron/releases). > > > > > > Missing step! How did the tarball get there? > > > > > > Also, I don’t think the tarball should be first pushed to github. What > > > benefit does this provide, vs just pushing directly to the dev repo ( > > > https://dist.apache.org/repos/dist/dev/incubator/metron )? > > > > > > Step 7 should state that the call for vote will include a link to the > RC > > > release in the dev repo. > > > > > > >>Creating a Maintenance Release > > > >> … if a critical JIRA comes in that requires an immediate patch we > may > > > forego steps 2-5 … > > > > > > Eh? I can see skipping steps 1 and 2, and abbreviating steps 5 and 6, > > but > > > steps 3 and 4 are purely mechanical and seem needed by definition to > > make a > > > release. Am I missing something? Perhaps the step # references are > > from a > > > prior draft? > > > > > > Also, regarding steps 7 and 8 (the votes), are Security break-fix > > releases > > > different in terms of voting requirements for Apache? > > > > > > Thanks, > > > --Matt > > > > > > > > > On 1/16/17, 12:03 PM, "James Sirota" <jsir...@apache.org> wrote: > > > > > > 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" <jsir...@apache.org>: > > > > 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 significant > > step > > > forward in feature capability and is denoted by an upgrade of the > second > > > digit > > > > Maintenance Release (MR) - this is a set of patches and fixes > that > > > are issued following the FR and is denoted by an upgrade of the third > > digit > > > > Release Naming Convention > > > > Metron build naming convention is as follows: 0.[FR].[MR]. We > keep > > > the 0. notation to signify that the project is still under active > > > development and we will hold a community vote to go to 1.x at a future > > time > > > > Initiating a New Metron Release > > > > Immediately upon the release of the previous Metron release > create > > > two branches: FR ++ and MR. Create the FR++ branch by incrementing the > > > second digit like so 0.[FR++].0. Create the MR branch for the previous > > > Metron release by incrementing the second digit of the previous release > > > like so 0.[FR].[MR]. All patches to the previous Metron release will be > > > checked in under the MR branch and where it makes sense also under the > FR > > > branch. All new features will be checked in under the FR branch. > > > > Creating a Feature Release > > > > Step 1 - Initiate a discuss thread > > > > Prior to the release The Release manager should do the following > > > (preferably a month before the release): > > > > Make sure that the list of JIRAs slated for the release > accurately > > > reflects to reflects the pull requests that are currently in master > > > > Construct an email to the Metron dev board ( > > > dev@metron.incubator.apache.org) which discusses with the community > the > > > desire to do a release. This email should contain the following: > > > > The list of JIRAs slated for the release with descriptions (use > the > > > output of git log and remove all the JIRAs from the last release’s > > > changelog) > > > > A solicitation of JIRAs that should be included with the next > > > release. Users should rate them as must/need/good to have as well as > > > volunteering. > > > > A release email template is provided here. > > > > Step 2 - Monitor and Verify JIRAs > > > > Once the community votes for additional JIRAs they want included > in > > > the release verify that the pull requests are in before the release, > > close > > > these JIRAs and tag them with the release name. All pull requests and > > JIRAs > > > that were not slated for this release will go into the next releases. > The > > > release manager should continue to monitor the JIRA to ensure that the > > > timetable is on track until the release date. On the release date the > > > release manager should message the Metron dev board ( > > > dev@metron.incubator.apache.org) announcing the code freeze for the > > > release. > > > > Step 3 - Create the Release Branch and Increment Metron version > > > > Create an branch for the release (from a repo cloned from > > > https://git-wip-us.apache.org/repos/asf/incubator-metron.git). > (assuming > > > the release is 0.[FR++].0 and working from master): > > > > git checkout -b Metron_0.[FR++].0 > > > > git push --set-upstream origin Metron_0.[FR++].0 > > > > File a JIRA to increment the Metron version to 0.[FR++].0. Either > > do > > > it yourself or have a community member increment the build version for > > you. > > > You can look at a pull request for a previous build to see how this is > > > done. METRON-533 - Up the version for release DONE > > > > Also, the release manager should have a couple of things set up: > > > > A SVN clone of the repo at https://dist.apache.org/repos/ > > > dist/dev/incubator/metron, We will refer to this as the dev repo. It > will > > > hold the release candidate artifacts > > > > A SVN clone of the repo at https://dist.apache.org/repos/ > > > dist/release/incubator/metron, We will refer to this as the release > repo. > > > It will hold the release artifacts. > > > > Step 4 - Create the Release Candidate > > > > > > > > Now, for each release candidate, we will tag from that branch. > > > Assuming that this is RC1: > > > > git checkout Metron_0.[FR++].0 && git pull > > > > git tag apache-metron-0.[FR++].0-rc1-incubating > > > > git push origin —tags > > > > > > > > Now, we must grab the release candidate binary from the github > > > releases page (https://github.com/apache/incubator-metron/releases). > In > > > our case, for RC1, that would be https://github.com/apache/ > > > incubator-metron/archive/apache-metron-0.[FR++].0-rc1- > incubating.tar.gz > > > We will refer to this as the release candidate tarball. > > > > The artifacts for a release (or a release candidate, for that > > > matter) are as follows: > > > > Release (candidate) Tarball > > > > MD5 hash of the release tarball (md5 apache-metron-Now, we must > > > grab the release candidate binary from the github releases page ( > > > https://github.com/apache/incubator-metron/releases). In our case, for > > > RC1, that would be https://github.com/apache/incubator-metron/archive/ > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz We will refer to this > as > > > the release candidate tarball.-rc1-incubating.tar.gz > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz.md5) > > > > SHA1 hash of the release tarball (gpg --print-md SHA1 > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz > > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz.sha) > > > > GPG signature of release tarball by the release manager > > > > Assuming your public code signing key is 0xDEADBEEF, so signing > > for > > > me would be: gpg -u 0xDEADBEEF --armor --output > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz.asc --detach-sig > > > apache-metron-0.[FR++].0-rc1-incubating.tar.gz > > > > If you do not know your code signing key as release manager, you > > > must follow the instructions at https://www.apache.org/dev/ > > > release-signing.html#generate > > > > Note: You only need the -u arg if you have more than one > > > public/private key pair generated. If you have forgotten it, you can > find > > > it from the output of gpg —fingerprint. It’s the last 4 bytes from the > > key > > > fingerprint. > > > > The LICENSE file from the release tarball > > > > The KEYS file from the release tarball > > > > The DISCLAIMER file from the release tarball > > > > A CHANGES file denoting the changes > > > > We usually construct this by taking the output of git log | grep > > > METRON | sed 's/\[//g' | sed 's/\]//g' | grep -v “http” and removing > the > > > JIRAs from the previous releases (it’s in time sorted order so this is > > > easy). > > > > > > > > Create a directory named ${VERSION}-RC${RC_NUM}-incubating (in > our > > > case, it’s 0.[FR++].0-RC1-incubating) in the dev repo. Place the > > artifacts > > > from above into this directory, add the directory and commit via the > > > subversion client: > > > > svn add 0.[FR++].0-RC1-incubating > > > > svn commit -m "Adding artifacts for Metron 0.[FR++].0-RC1 > > > (incubating)” > > > > Step 5 - Verify the build > > > > Go through the build verification checklist to verify that > > > everything works. These instructions can be found here: Verifying > Builds > > > > Step 6 - Verify licensing > > > > Make sure the release compiles with the following Apache > licensing > > > guidelines: http://www.apache.org/foundation/license-faq.html > > > > Step 7 - Call for a community release vote > > > > Next initiate a [VOTE] threat on the dev list to announce the > build > > > vote. The vote email template can be found here: Build Vote Template. > > Allow > > > at least 72 hours for the community to vote on the release. When you > get > > > enough votes close the vote by replying [RESULT][VOTE] to the email > > thread > > > with the tally of all the votes > > > > Step 8 - Call for a incubator release vote > > > > Once the community has successfully voted on a release, we must > > > escalate the vote to the incubator general. The same VOTE thread > original > > > email is sent to gene...@incubator.apache.org > > > > > > > > If issues are found with the release and the vote fails, then the > > > vote thread is closed with a synopsis of the voting results and a new > RC > > is > > > worked on in the community > > > > If issues are found with the release and the vote succeeds, then > we > > > proceed to cut the release, but should notify the community of the > issues > > > via an email on the dev list with the accompanying JIRA(s) required to > > > correct the issue(s). > > > > > > > > If no issues are found, then we can cut a release > > > > Again, wait for at least 72 hours and then close the vote. > > > > Step 9 - Stage the finished release > > > > A directory with the name of the version (i.e. 0.3.0) should be > > made > > > in the release svn repository > > > > > > > > Collateral from the release candidate in the dev repo should be > > > moved to the above directory and renamed to remove the rc (e.g. mv > > > apache-metron-0.3.0-rc1-incubating.tar.gz.sha apache-metron-0.3.0- > > > incubating.tar.gz.sha) > > > > > > > > Add the directory and commit via the subversion client: > > > > > > > > svn add 0.3.0-RC1-incubating > > > > svn commit -m "Adding artifacts for Metron 0.3.0 (incubating)” > > > > > > > > Remove the old releases from the release repo (only the current > > > version and the KEYS file should exist there). > > > > Step 14 - Announce build > > > > Send an email out to user@ and dev@ to announce the release > along > > > with the changelog and a word of thanks/praise. > > > > Creating a Maintenance Release > > > > Creation of the Maintenance Release should follow exactly the > same > > > set of steps as creating the Feature Release as outlined above, but > with > > > two exception. First, the version incremented on the maintenance > release > > > should be the MR++ so that the release is named 0.[FR].[MR++]. Second, > > if a > > > critical JIRA comes in that requires an immediate patch we may forego > > steps > > > 2-5 and immediately cut the MR release. A critical JIRA is something > that > > > is either a security vulnerability or a functional show stopper . > > > > Ensuring Consistency between Feature and Maintenance releases > > > > 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 feature > code > > > proceeds as fast as the community wishes. It is important to assure > that > > > all commits to the maintenance release also get made in the feature > > branch > > > (if relevant), to avoid the appearance of regressions in the > maintenance > > > branch. The formal process for assuring this is as follows: > > > > Every maintenance release JIRA should have a corresponding > feature > > > JIRA to make sure that the patch is applied consistently to both > > branches. > > > The maintenance JIRA should be cloned and appropriate fix version for > the > > > feature release should be applied. If the fix is not relevant to the > > > feature or maintenance branch then the submitter must explicitly state > > > this. In general reviewers should refuse a patch PR unless both feature > > and > > > maintenance JIRAs have been created. > > > > The release manager has a responsibility to review all commits to > > > the maintenance line since last release, and make sure they were > > duplicated > > > to the feature branch (unless not relevant, which must also be > > determined). > > > > > > > > 05.01.2017, 06:32, "larry mccay" <lmc...@apache.org>: > > > >> 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 outside of the rc. This decoupling is supposed to > > make > > > it more > > > >> difficult for an artifact to be tampered with and another KEYS > > file > > > >> provided. I think most projects that keep the KEYS separate > just > > > put them at > > > >> the top level of the ASF mirror area for the project such as at > > > >> https://dist.apache.org/repos/dist/*release*/incubator/metron/ > > > [1]. > > > >> * Related to the above, it seems that in the KEYS file is > > > duplicated at the > > > >> top level of the ASF mirror area for the project as well as in > > the > > > release > > > >> directory. The one inside the release directory would probably > go > > > away by > > > >> addressing the previous comment but it should be noted that > there > > > is a > > > >> chance for those two files to be out of sync otherwise. > > > >> * I notice that the DISCLAIMER, LICENSE and CHANGES files are > > kept > > > outside > > > >> of the archives along with the KEYS file. As long as they are > > also > > > inside > > > >> the archive it is probably fine but I don't think there is a > need > > > for > > > >> LICENSE and DISCLAIMER to be outside. In Knox we do keep the > > > CHANGES > > > >> outside as well so that it can be easily reviewed to determine > > > interest or > > > >> need for upgrade etc. > > > >> * I do also notice that there is no zip archive - you may want > to > > > consider > > > >> adding a zip as well. > > > >> * steps 10 and 13 instruct the release manager to stage the rc > > and > > > the > > > >> final release but there aren't any instructions as to how to do > > > so. Is that > > > >> documented elsewhere? We have specific ant targets to run for > > > >> stage-candidate and promote-release [2]. > > > >> > > > >> Hope this is helpful. > > > >> > > > >> 1. https://www.apache.org/dev/release-signing.html#keys-policy > > > >> 2. > > > >> https://cwiki.apache.org/confluence/display/KNOX/ > > Release+Process# > > > ReleaseProcess-Stage > > > >> > > > >> thanks, > > > >> > > > >> --larry > > > >> > > > >> On Wed, Jan 4, 2017 at 7:25 PM, Matt Foley <ma...@apache.org> > > > wrote: > > > >> > > > >>> 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" <jsir...@apache.org> > wrote: > > > >>> > > > >>> 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 Release (FR) - this is a release that has a > > > significant step > > > >>> forward in feature capability and is denoted by an upgrade of > > > the second > > > >>> digit > > > >>> Maintenance Release (MR) - this is a set of patches and > > > fixes that are > > > >>> issued following the FR and is denoted by an upgrade of the > > > third digit > > > >>> Release Naming Convention > > > >>> Metron build naming convention is as follows: > 0.[FR].[MR]. > > > We keep > > > >>> the 0. notation to signify that the project is still under > > active > > > >>> development and we will hold a community vote to go to 1.x > at a > > > future time > > > >>> Initiating a New Metron Release > > > >>> Immediately upon the release of the previous Metron > release > > > create two > > > >>> branches: FR ++ and MR. Create the FR++ branch by > incrementing > > > the second > > > >>> digit like so 0.[FR++].0. Create the MR branch for the > previous > > > Metron > > > >>> release by incrementing the second digit of the previous > > release > > > like so > > > >>> 0.[FR].[MR]. All patches to the previous Metron release will > be > > > checked in > > > >>> under the MR branch and where it makes sense also under the > FR > > > branch. All > > > >>> new features will be checked in under the FR branch. > > > >>> Creating a Feature Release > > > >>> Step 1 - Initiate a discuss thread > > > >>> A week before a new feature release initiate a discuss > > > thread on the > > > >>> Metron dev board announcing the upcoming release and asking > the > > > community > > > >>> which still outstanding pull requests people want to include > in > > > the next > > > >>> build. > > > >>> Step 2 - Verify JIRA > > > >>> Go through the JIRA and verify that all pull requests > that > > > were merged > > > >>> for the upcoming build have JIRAs that are in a closed state > > and > > > are > > > >>> appropriately labelled with the next build version. > > > >>> Step 3 - Announce a code freeze > > > >>> A day before the release date comment on the discuss > thread > > > and let > > > >>> people know that the release is ready. Go through the JIRAs > for > > > pull > > > >>> requests that came in during the last week and make sure they > > > are labelled > > > >>> with the next build version. > > > >>> Step 4 - Increment Metron version > > > >>> File a JIRA to increment the Metron version to > 0.[FR++].0. > > > Either do > > > >>> it yourself or have a community member increment the build > > > version for > > > >>> you. You can look at a pull request for a previous build to > see > > > how this > > > >>> is done > > > >>> Step 5 - Increment build version > > > >>> File a JIRA to increment the Metron version to > > > 0.[FR++].0-RC(n), where > > > >>> RC(n) is the number of the release candidate. Sometimes > > mistakes > > > occur > > > >>> (builds may get voted down) so it will take multiple RCs to > get > > > a build > > > >>> through the vote. The RC(n) will be removed after the > > successful > > > vote. > > > >>> Step 6 - Verify the build > > > >>> Go through the build verification checklist to verify > that > > > everything > > > >>> works. These instructions can be found here: Verifying Builds > > > >>> Step 7 - Verify licensing > > > >>> Make sure the release compiles with the following Apache > > > licensing > > > >>> guidelines: http://www.apache.org/ > foundation/license-faq.html > > > >>> Step 8 - Generate the changes file > > > >>> Go through the JIRA to generate the changes file, which > > > contains a > > > >>> list of all JIRAs included in the upcoming release. An > example > > > of a > > > >>> changes file can be found here: > https://dist.apache.org/repos/ > > > >>> dist/dev/incubator/metron/0.3.0-RC1-incubating/CHANGES > > > >>> Step 9 - Tag the RC release > > > >>> Tag the release for the RC in case we need to roll back > at > > > some > > > >>> point. An example of a valid tag can be seen here: > > > >>> https://git-wip-us.apache.org/ > repos/asf?p=incubator-metron > > . > > > >>> git;a=shortlog;h=refs/tags/apache-metron-0.3.0-rc1- > incubating > > > >>> Step 10 - Stage the release > > > >>> The next thing to do is to sign and stage the release > > > including the > > > >>> DISCLAIMER, KEYS, and LICENSE files. A properly signed and > > > staged release > > > >>> can be found here: > > > >>> https://dist.apache.org/repos/ > > dist/dev/incubator/metron/0.3. > > > >>> 0-RC1-incubating/ > > > >>> * Make sure you have your correct profile and keys > uploaded > > > to > > > >>> https://id.apache.org/ to properly sign the release and to > get > > > access to > > > >>> dist.apache.org > > > >>> Step 11 - Call for a community release vote > > > >>> Next initiate a [VOTE] threat on the dev list to announce > > > the build > > > >>> vote. The vote email template can be found here: Build Vote > > > Template. > > > >>> Allow at least 72 hours for the community to vote on the > > > release. When you > > > >>> get enough votes close the vote by replying [RESULT][VOTE] to > > > the email > > > >>> thread with the tally of all the votes > > > >>> Step 12 - Call for a incubator release vote > > > >>> Upon successful completion of step 11, repeat, but now > send > > > the email > > > >>> to the incubator general boards. The email should be > identical. > > > Again, > > > >>> wait for at least 72 hours and then close the vote. > > > >>> Step 13 - Stage the finished release > > > >>> If the vote fails at any stage then incorporate feedback, > > > create > > > >>> another RC, and repeat. If both votes pass then stage the > > > resulting > > > >>> artifacts here: https://dist.apache.org/repos/ > > > >>> dist/release/incubator/metron/ > > > >>> Step 14 - Announce build > > > >>> Send a discuss thread to the Metron dev boards announcing > > > the new > > > >>> Metron build > > > >>> Creating a Maintenance Release > > > >>> Creation of the Maintenance Release should follow exactly > > > the same set > > > >>> of steps as creating the Feature Release as outlined above, > but > > > with two > > > >>> exception. First, the version incremented on the maintenance > > > release > > > >>> should be the MR++ so that the release is named > 0.[FR].[MR++]. > > > Second, if > > > >>> a critical JIRA comes in that requires an immediate patch we > > may > > > forego > > > >>> steps 2-5 and immediately cut the MR release. A critical JIRA > > is > > > something > > > >>> that is either a security vulnerability or a functional show > > > stopper . > > > >>> Ensuring Consistency between Feature and Maintenance > > releases > > > >>> 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 feature code > > > proceeds as > > > >>> fast as the community wishes. It is important to assure that > > all > > > commits > > > >>> to the maintenance release also get made in the feature > branch > > > (if > > > >>> relevant), to avoid the appearance of regressions in the > > > maintenance > > > >>> branch. The formal process for assuring this is as follows: > > > >>> Every maintenance release JIRA should have a > corresponding > > > feature > > > >>> JIRA to make sure that the patch is applied consistently to > > both > > > branches. > > > >>> The maintenance JIRA should be cloned and appropriate fix > > > version for the > > > >>> feature release should be applied. If the fix is not relevant > > to > > > the > > > >>> feature or maintenance branch then the submitter must > > explicitly > > > state > > > >>> this. In general reviewers should refuse a patch PR unless > both > > > feature > > > >>> and maintenance JIRAs have been created. > > > >>> The release manager has a responsibility to review all > > > commits to the > > > >>> maintenance line since last release, and make sure they were > > > duplicated to > > > >>> the feature branch (unless not relevant, which must also be > > > determined). > > > >>> > > > >>> 20.12.2016, 11:45, "Matt Foley" <ma...@apache.org>: > > > >>> > 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 as fast as the community wishes. > > > >>> > a. As Kyle points out, it is important to assure that > all > > > commits to > > > >>> the maintenance line also get made in the mainline (if > > > relevant), to avoid > > > >>> the appearance of regressions in the mainline. There should > be > > a > > > formal > > > >>> process for assuring this. Possibilities are: > > > >>> > i. The release manager has a responsibility to review > all > > > commits to > > > >>> the maint line since last release, and make sure they were > > > duplicated to > > > >>> the mainline (unless not relevant, which must also be > > > determined). > > > >>> > ii. Reviewers refuse to accept PRs for the maint line > > > unless they > > > >>> are twinned with PRs for corresponding changes in the > mainline > > > (unless not > > > >>> relevant, which must be stated by the submitter). This should > > be > > > reflected > > > >>> in Jira practices as well as PR practices. Note Jira is poor > at > > > tracking > > > >>> multiple “Fix Version/s” values (due to the ambiguous use of > > > “Fix version” > > > >>> to mean both “target version” and “done version”). Most teams > > > just clone > > > >>> jira tickets for multiple target releases. > > > >>> > 2. Agree. Being a release manager is a significant > > > commitment of > > > >>> both time and care, and should be rotated around; both for > the > > > benefit of > > > >>> the individuals involved and so that at least 2 or 3 people > are > > > deeply > > > >>> familiar with the process at any given time. > > > >>> > --Matt > > > >>> > > > > >>> > On 12/20/16, 8:15 AM, "James Sirota" < > jsir...@apache.org > > > > > > wrote: > > > >>> > > > > >>> > 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 > > > > > > > > ------------------- > > > > 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 > > > > > > > > > > > > > > > > > >
