subject:"\[DISCUSS\] Release Process"

Re: [DISCUSS] Release Process

2017-01-18 Thread Otto Fowler

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 (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  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?
> 
>
> Strictly speaking, releases must be verified
>  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  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  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

Re: [DISCUSS] Release Process

2017-01-17 Thread James Sirota

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 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 idea, I can release them and
> figure out the steps during our next release and then vote on a
> modification to this doc afterwards. Thoughts?
>
> Casey
>
> On Tue, Jan 17, 2017 at 3:43 PM, Matt Foley  wrote:
>
> > Casey and James,
> > Do we also want to include in the Release Process that we publish Maven
> > artifacts? The (detailed) procedures for Apache conformance
> > are in http://www.apache.org/dev/publishing-maven-artifacts.html
> >
> > This probably wants to be integrated with our build tools.
> >
> > This is optional, so we could leave it for later.
> >
> > Thanks,
> > --Matt
> >
> >
> >
> > On 1/17/17, 12: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 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 
> > 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?
> > > 
> > >
> > > Strictly speaking, releases must be verified
> > >  > > 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 
> > 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

Re: [DISCUSS] Release Process

2017-01-17 Thread Matt Foley

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 idea, I can release them and
figure out the steps during our next release and then vote on a
modification to this doc afterwards.  Thoughts?

Casey

On Tue, Jan 17, 2017 at 3:43 PM, Matt Foley  wrote:

> Casey and James,
> Do we also want to include in the Release Process that we publish Maven
> artifacts?  The (detailed) procedures for Apache conformance
> are in http://www.apache.org/dev/publishing-maven-artifacts.html
>
> This probably wants to be integrated with our build tools.
>
> This is optional, so we could leave it for later.
>
> Thanks,
> --Matt
>
>
>
> On 1/17/17, 12: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 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 
> 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?
> > 
> >
> > Strictly speaking, releases must be verified
> >  > 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 
> 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
>

Re: [DISCUSS] Release Process

2017-01-17 Thread larry mccay

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 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  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?
> > 
> >
> > Strictly speaking, releases must be verified
> >  > 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 
> 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  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.
>

Re: [DISCUSS] Release Process

2017-01-17 Thread larry mccay

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

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

Re: [DISCUSS] Release Process

2017-01-17 Thread Casey Stella

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

Re: [DISCUSS] Release Process

2017-01-17 Thread Casey Stella

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

Re: [DISCUSS] Release Process

2017-01-16 Thread Matt Foley

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

Re: [DISCUSS] Release Process

2017-01-16 Thread Otto Fowler

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

Re: [DISCUSS] Release Process

2017-01-16 Thread James Sirota

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

Re: [DISCUSS] Release Process

2017-01-10 Thread James Sirota

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 >

Re: [DISCUSS] Release Process

2017-01-05 Thread larry mccay

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

Re: [DISCUSS] Release Process

2017-01-04 Thread Matt Foley

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?

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

Re: [DISCUSS] Release Process

2017-01-04 Thread James Sirota

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

Re: [DISCUSS] Release Process

2016-12-20 Thread Matt Foley

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

Re: [DISCUSS] Release Process

2016-12-20 Thread James Sirota

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 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" :
>>  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  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" :
>>>   > 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  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 
>>>   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" :
>>>   >> > I made some minor changes to the doc - check out the history
>>>   >> > >>   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
>>>   >> >  most
>>>   >> >  recent
>>>   >> >  build
>>>   >> >  failures
>>>   >> >  as a valuable
>>>   case
>>>   >> > study.
>>>   >> >
>>>   >> > Jon
>>>   >> >
>>>   >> > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
>>>   >> wrote:
>>>   >> >
>>>   >> >> I threw together a draft document for our release process. Would you
>>>   >>

Re: [DISCUSS] Release Process

2016-12-20 Thread James Sirota

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" :
> 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  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" :
>>  > 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  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 
>>  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" :
>>  >> > I made some minor changes to the doc - check out the history
>>  >> > >  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
>>  >> >  most
>>  >> >  recent
>>  >> >  build
>>  >> >  failures
>>  >> >  as a valuable
>>  case
>>  >> > study.
>>  >> >
>>  >> > Jon
>>  >> >
>>  >> > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
>>  >> 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,
>>  >>
>>

Re: [DISCUSS] Release Process

2016-12-18 Thread Kyle Richardson

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  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" :
> > 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  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 
> 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" :
> >>  > I made some minor changes to the doc - check out the history
> >>  >  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
> >>  >  most
> >>  >  recent
> >>  >  build
> >>  >  failures
> >>  >  as a valuable
> case
> >>  > study.
> >>  >
> >>  > Jon
> >>  >
> >>  > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
> >>  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 
> >
> > --
> >
> > Jon
> >
> > Sent from my mobile device
>
> ---
> Thank you,
>
> James Sirota
> PPMC- Apache Metron (Incubating)
> jsirota AT apache DOT org
>

Re: [DISCUSS] Release Process

2016-12-16 Thread James Sirota

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 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  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  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" :
>>  > I made some minor changes to the doc - check out the history
>>  > >  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
>>  >  most
>>  >  recent
>>  >  build
>>  >  failures
>>  >  as a valuable case
>>  > study.
>>  >
>>  > Jon
>>  >
>>  > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
>>  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 
>
> --
>
> Jon
>
> Sent from my mobile device

--- 
Thank you,

James Sirota
PPMC- Apache Metron (Incubating)
jsirota AT apache DOT org

Re: [DISCUSS] Release Process

2016-12-16 Thread 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  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  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" :
> > I made some minor changes to the doc - check out the history
> >  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
> >  most
> >  recent
> >  build
> >  failures
> >  as a valuable case
> > study.
> >
> > Jon
> >
> > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
> 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 

-- 

Jon

Sent from my mobile device

Re: [DISCUSS] Release Process

2016-12-16 Thread Nick Allen

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  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" :
> > I made some minor changes to the doc - check out the history
> >  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
> >  most
> >  recent
> >  build
> >  failures
> >  as a valuable case
> > study.
> >
> > Jon
> >
> > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
> 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

Re: [DISCUSS] Release Process

2016-12-16 Thread Casey Stella

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, "zeo...@gmail.com" :
> > I made some minor changes to the doc - check out the history
> >  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
> >  most
> >  recent
> >  build
> >  failures
> >  as a valuable case
> > study.
> >
> > Jon
> >
> > On Fri, Dec 16, 2016 at 11:38 AM James Sirota 
> 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
>

Re: [DISCUSS] Release Process

2016-12-16 Thread James Sirota

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
> 
> 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
>  most
>  recent
>  build
>  failures
>  as a valuable case
> study.
>
> Jon
>
> On Fri, Dec 16, 2016 at 11:38 AM James Sirota  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

Re: [DISCUSS] Release Process

2016-12-16 Thread zeo...@gmail.com

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 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
 most
 recent
 build
 failures
 as a valuable case
study.

Jon

On Fri, Dec 16, 2016 at 11:38 AM James Sirota  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

[DISCUSS] Release Process

2016-12-16 Thread James Sirota

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

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

Re: [DISCUSS] Release Process

[DISCUSS] Release Process

25 matches

Site Navigation

Mail list logo

Footer information