You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2015/10/12 00:03:20 UTC
Commit policy question
Has anything changed in regard to branching since I last contributed? I
pushed a commit to master to fix a bug, but I forgot to make sure that was
still the right way to do things (especially with an RC going on).
--
Matt Sicker <bo...@gmail.com>
Re: Commit policy question
Posted by Matt Sicker <bo...@gmail.com>.
I've noticed that this bug I worked on is part of a different bug that
can't be fixed nearly as quickly, so no worries.
On 11 October 2015 at 18:34, Ralph Goers <ra...@dslextreme.com> wrote:
> Before the release candidate is created we normally discuss any
> outstanding issues that need to be fixed and wait for those to be addressed
> before the release build is performed. Unfortunately, you missed that
> discussion for this release.
>
> Ralph
>
> On Oct 11, 2015, at 4:29 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Alright, got it. I'm retracting the vote as I haven't tested the RC yet
> anyway.
>
> On 11 October 2015 at 18:27, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> That’s not are reason to redo a release candidate, especially since I
>> think that bug has been around a while.
>>
>> As a reminder, your vote means that you have downloaded and inspected the
>> release candidate and didn’t find any defects that are showstoppers, both
>> in terms of operation and packaging. So something like a severe performance
>> degradation, binary compatibility breakage, missing license headers,
>> artifacts that are improperly signed, etc are all reasons to vote -1 on a
>> release.
>>
>> Ralph
>>
>>
>> On Oct 11, 2015, at 4:11 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> It's a rather minor change that would fix a bug marked critical, so it
>> could be worth redoing the RC. I'll make a vote on that.
>>
>> On 11 October 2015 at 17:30, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> Also, your vote is still binding so if you want to review and vote on
>>> the release you can. That said, I understand if you want to take some time
>>> and get acquainted with the code again.
>>>
>>> Ralph
>>>
>>> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>> No nothing has really changed. I have a branch I am waiting to commit to
>>> master since I don’t want it included if I have to create another release
>>> candidate. That wouldn’t be a problem for simple bug fixes.
>>>
>>> Ralph
>>>
>>> On Oct 11, 2015, at 3:03 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> Has anything changed in regard to branching since I last contributed? I
>>> pushed a commit to master to fix a bug, but I forgot to make sure that was
>>> still the right way to do things (especially with an RC going on).
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Commit policy question
Posted by Ralph Goers <ra...@dslextreme.com>.
Before the release candidate is created we normally discuss any outstanding issues that need to be fixed and wait for those to be addressed before the release build is performed. Unfortunately, you missed that discussion for this release.
Ralph
> On Oct 11, 2015, at 4:29 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Alright, got it. I'm retracting the vote as I haven't tested the RC yet anyway.
>
> On 11 October 2015 at 18:27, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> That’s not are reason to redo a release candidate, especially since I think that bug has been around a while.
>
> As a reminder, your vote means that you have downloaded and inspected the release candidate and didn’t find any defects that are showstoppers, both in terms of operation and packaging. So something like a severe performance degradation, binary compatibility breakage, missing license headers, artifacts that are improperly signed, etc are all reasons to vote -1 on a release.
>
> Ralph
>
>
>> On Oct 11, 2015, at 4:11 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>> It's a rather minor change that would fix a bug marked critical, so it could be worth redoing the RC. I'll make a vote on that.
>>
>> On 11 October 2015 at 17:30, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>> Also, your vote is still binding so if you want to review and vote on the release you can. That said, I understand if you want to take some time and get acquainted with the code again.
>>
>> Ralph
>>
>>> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>>
>>> No nothing has really changed. I have a branch I am waiting to commit to master since I don’t want it included if I have to create another release candidate. That wouldn’t be a problem for simple bug fixes.
>>>
>>> Ralph
>>>
>>>> On Oct 11, 2015, at 3:03 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> Has anything changed in regard to branching since I last contributed? I pushed a commit to master to fix a bug, but I forgot to make sure that was still the right way to do things (especially with an RC going on).
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>>
>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Commit policy question
Posted by Matt Sicker <bo...@gmail.com>.
Alright, got it. I'm retracting the vote as I haven't tested the RC yet
anyway.
On 11 October 2015 at 18:27, Ralph Goers <ra...@dslextreme.com> wrote:
> That’s not are reason to redo a release candidate, especially since I
> think that bug has been around a while.
>
> As a reminder, your vote means that you have downloaded and inspected the
> release candidate and didn’t find any defects that are showstoppers, both
> in terms of operation and packaging. So something like a severe performance
> degradation, binary compatibility breakage, missing license headers,
> artifacts that are improperly signed, etc are all reasons to vote -1 on a
> release.
>
> Ralph
>
>
> On Oct 11, 2015, at 4:11 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It's a rather minor change that would fix a bug marked critical, so it
> could be worth redoing the RC. I'll make a vote on that.
>
> On 11 October 2015 at 17:30, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Also, your vote is still binding so if you want to review and vote on the
>> release you can. That said, I understand if you want to take some time and
>> get acquainted with the code again.
>>
>> Ralph
>>
>> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> No nothing has really changed. I have a branch I am waiting to commit to
>> master since I don’t want it included if I have to create another release
>> candidate. That wouldn’t be a problem for simple bug fixes.
>>
>> Ralph
>>
>> On Oct 11, 2015, at 3:03 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Has anything changed in regard to branching since I last contributed? I
>> pushed a commit to master to fix a bug, but I forgot to make sure that was
>> still the right way to do things (especially with an RC going on).
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Commit policy question
Posted by Gary Gregory <ga...@gmail.com>.
+1, I would not VOTE -1 to _add_ something to a release, only if something
is broken with the RC.
Gary
On Sun, Oct 11, 2015 at 4:27 PM, Ralph Goers <ra...@dslextreme.com>
wrote:
> That’s not are reason to redo a release candidate, especially since I
> think that bug has been around a while.
>
> As a reminder, your vote means that you have downloaded and inspected the
> release candidate and didn’t find any defects that are showstoppers, both
> in terms of operation and packaging. So something like a severe performance
> degradation, binary compatibility breakage, missing license headers,
> artifacts that are improperly signed, etc are all reasons to vote -1 on a
> release.
>
> Ralph
>
>
> On Oct 11, 2015, at 4:11 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It's a rather minor change that would fix a bug marked critical, so it
> could be worth redoing the RC. I'll make a vote on that.
>
> On 11 October 2015 at 17:30, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Also, your vote is still binding so if you want to review and vote on the
>> release you can. That said, I understand if you want to take some time and
>> get acquainted with the code again.
>>
>> Ralph
>>
>> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>> No nothing has really changed. I have a branch I am waiting to commit to
>> master since I don’t want it included if I have to create another release
>> candidate. That wouldn’t be a problem for simple bug fixes.
>>
>> Ralph
>>
>> On Oct 11, 2015, at 3:03 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Has anything changed in regard to branching since I last contributed? I
>> pushed a commit to master to fix a bug, but I forgot to make sure that was
>> still the right way to do things (especially with an RC going on).
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Commit policy question
Posted by Ralph Goers <ra...@dslextreme.com>.
That’s not are reason to redo a release candidate, especially since I think that bug has been around a while.
As a reminder, your vote means that you have downloaded and inspected the release candidate and didn’t find any defects that are showstoppers, both in terms of operation and packaging. So something like a severe performance degradation, binary compatibility breakage, missing license headers, artifacts that are improperly signed, etc are all reasons to vote -1 on a release.
Ralph
> On Oct 11, 2015, at 4:11 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> It's a rather minor change that would fix a bug marked critical, so it could be worth redoing the RC. I'll make a vote on that.
>
> On 11 October 2015 at 17:30, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> Also, your vote is still binding so if you want to review and vote on the release you can. That said, I understand if you want to take some time and get acquainted with the code again.
>
> Ralph
>
>> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
>>
>> No nothing has really changed. I have a branch I am waiting to commit to master since I don’t want it included if I have to create another release candidate. That wouldn’t be a problem for simple bug fixes.
>>
>> Ralph
>>
>>> On Oct 11, 2015, at 3:03 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Has anything changed in regard to branching since I last contributed? I pushed a commit to master to fix a bug, but I forgot to make sure that was still the right way to do things (especially with an RC going on).
>>>
>>> --
>>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>>
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Commit policy question
Posted by Matt Sicker <bo...@gmail.com>.
It's a rather minor change that would fix a bug marked critical, so it
could be worth redoing the RC. I'll make a vote on that.
On 11 October 2015 at 17:30, Ralph Goers <ra...@dslextreme.com> wrote:
> Also, your vote is still binding so if you want to review and vote on the
> release you can. That said, I understand if you want to take some time and
> get acquainted with the code again.
>
> Ralph
>
> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ra...@dslextreme.com>
> wrote:
>
> No nothing has really changed. I have a branch I am waiting to commit to
> master since I don’t want it included if I have to create another release
> candidate. That wouldn’t be a problem for simple bug fixes.
>
> Ralph
>
> On Oct 11, 2015, at 3:03 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Has anything changed in regard to branching since I last contributed? I
> pushed a commit to master to fix a bug, but I forgot to make sure that was
> still the right way to do things (especially with an RC going on).
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Commit policy question
Posted by Ralph Goers <ra...@dslextreme.com>.
Also, your vote is still binding so if you want to review and vote on the release you can. That said, I understand if you want to take some time and get acquainted with the code again.
Ralph
> On Oct 11, 2015, at 3:28 PM, Ralph Goers <ra...@dslextreme.com> wrote:
>
> No nothing has really changed. I have a branch I am waiting to commit to master since I don’t want it included if I have to create another release candidate. That wouldn’t be a problem for simple bug fixes.
>
> Ralph
>
>> On Oct 11, 2015, at 3:03 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
>>
>> Has anything changed in regard to branching since I last contributed? I pushed a commit to master to fix a bug, but I forgot to make sure that was still the right way to do things (especially with an RC going on).
>>
>> --
>> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
Re: Commit policy question
Posted by Ralph Goers <ra...@dslextreme.com>.
No nothing has really changed. I have a branch I am waiting to commit to master since I don’t want it included if I have to create another release candidate. That wouldn’t be a problem for simple bug fixes.
Ralph
> On Oct 11, 2015, at 3:03 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Has anything changed in regard to branching since I last contributed? I pushed a commit to master to fix a bug, but I forgot to make sure that was still the right way to do things (especially with an RC going on).
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>