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