You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by Bobby Evans <ev...@yahoo-inc.com.INVALID> on 2014/06/26 17:56:56 UTC
[VOTE] Storm Bylaws try 2
I have updated the proposed bylaws following Nathan and Taylor’s suggestions. They the only parts edited were the title to indicate that these are proposed bylaws and will not officially be adopted until we are a top level project, and the voting on code changes to reflect that a +1 from the author of the patch is not counted.
You can find them here.
https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
The new voting is consensus approval with (P)PMC members casting binding votes.
- Bobby
Re: [VOTE] Storm Bylaws try 2
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
I just put up https://github.com/apache/incubator-storm/pull/173 for this.
On 6/30/14, 11:43 AM, "Bobby Evans" <ev...@yahoo-inc.com.INVALID> wrote:
>How about I update the document to take into account Nathan¹s comments.
>Then turn it into a formal pull request. Then we can continue the
>discussion, and put more pull requests on top of it until we graduate and
>have a formal vote on adoption. Then at that point we can move the bylaws
>into the subversion web page repo, or add a link to the github repo for
>the bylaws. Either way is fine with me.
>
>I am canceling the vote.
>
>- Bobby
>
>On 6/28/14, 3:15 PM, "P. Taylor Goetz" <pt...@gmail.com> wrote:
>
>>I agree completely!
>>
>>I think adding ³work in progress² or ³DRAFT² in the title will prevent
>>any confusion. And maybe cancel the vote and treat it more like a patch
>>for now. Then when it¹s time to formally adopt the bylaws, we can hold
>>the official vote.
>>
>>- Taylor
>>
>>On Jun 28, 2014, at 2:31 PM, Nathan Marz <na...@nathanmarz.com> wrote:
>>
>>> My impression was that this was a vote to adopt the bylaws, since it
>>>says
>>> "proposed bylaws" and the vote required consensus approval.
>>>
>>> Regardless, I agree that we should merge it into source control and
>>> collaborate on it with pull requests/comments, and we should delay a
>>>vote
>>> until everyone's issues have been addressed. However, let's add "work
>>>in
>>> progress" to the title so people don't get confused.
>>>
>>>
>>> On Sat, Jun 28, 2014 at 7:30 AM, P. Taylor Goetz <pt...@gmail.com>
>>>wrote:
>>>
>>>> I¹m +1.
>>>>
>>>> I think with Bobby¹s latest changes it makes it abundantly clear that
>>>>it
>>>> is a working draft, and we are not voting to adopt them. I see this as
>>>>a
>>>> vote to pull the draft into source control so individual changes can
>>>>be
>>>> proposed and discussed as opposed to trying to approve the document in
>>>>it¹s
>>>> entirety.
>>>>
>>>> Trying to get everything right all at once places undue burden on
>>>>Bobby ‹
>>>> a veto forces him to cancel the vote, interpret the comments, reword
>>>>things
>>>> to address the comments, and initiate a new vote. Bobby was kind
>>>>enough to
>>>> put it together in the first place.
>>>>
>>>> I think it would be more efficient if we just staged it in source
>>>>control
>>>> (we wouldn¹t have to publish it to the website), and allow people to
>>>> collaborate by proposing changes/patches that can be discussed and
>>>>applied
>>>> individually. Again, the document doesn¹t carry any weight until it is
>>>> finalized and formally adopted.
>>>>
>>>>> Lastly, I want to address something that Taylor said in the previous
>>>>> discussion:
>>>>>
>>>>> 'Understood. Also be aware that lazy consensus can be invoked for
>>>>>code
>>>>> changes by declaring so in the pull request: ³I will assume lazy
>>>> consensus
>>>>> on this and commit the change in X hours if there are no -1 votes.²
>>>>
>>>> That should have read ³days² instead of ³hours,² so it came across a
>>>> little more drastic than intended...
>>>>
>>>>>
>>>>> I think Hadoop uses lazy consensus as the default, but I¹d have to
>>>> check.'
>>>>>
>>>>> I'm not sure where "be aware that lazy consensus can be invoked for
>>>>>code
>>>>> changes by declaring so in the pull request" came from. Is this a
>>>>>rule
>>>> that
>>>>> Hadoop or other Apache projects use? Ultimately each project
>>>>>determines
>>>> for
>>>>> themselves the rules for committing what Hadoop or other projects
>>>>>do
>>>> has
>>>>> no relevance on Storm. This is certainly not something we ever agreed
>>>>>to
>>>>> for the governance of Storm.
>>>>
>>>> That came from here [1]. But looking at it again it seems to conflict
>>>>with
>>>> a RTC policy (even though some projects seem to use lazy consensus
>>>>with
>>>> RTC). So I stand corrected.
>>>>
>>>> My point is that yes, other Apache projects do use lazy consensus for
>>>>code
>>>> changes, so it is an option that open to us if we so choose. Nothing
>>>>more.
>>>>
>>>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's
>>>> development
>>>>> has gone through some pretty ridiculous things, like the completely
>>>> broken
>>>>> record append implementation and the fiasco around the mapred.* and
>>>>> mapreduce.* namespaces. I believe Storm to be a much higher quality
>>>>>piece
>>>>> of software (though not perfect, of course) and we should try keep it
>>>> that
>>>>> way.
>>>>
>>>>
>>>> I never meant to imply that we should aspire to be like Hadoop. I was
>>>> merely using it as an example in the context of a bylaws discussion.
>>>>
>>>> If there¹s on goal we all share, I think it¹s to make Storm the
>>>>highest
>>>> quality piece of software we can. That¹s why we¹re here.
>>>>
>>>> No project is perfect. We will inevitably make mistakes, fix them,
>>>>learn
>>>> from them, and grow stronger as a community in the process.
>>>>
>>>> - Taylor
>>>>
>>>> [1] http://www.apache.org/foundation/voting.html
>>>>
>>>>
>>>> On Jun 27, 2014, at 8:16 PM, Nathan Marz <na...@nathanmarz.com>
>>>>wrote:
>>>>
>>>>> -1 (binding)
>>>>>
>>>>> I've given this quite a bit of thought, and I think we need to be
>>>>>more
>>>>> explicit in the bylaws in a few places.
>>>>>
>>>>> 1. Code changes:
>>>>> I've reverted a bit and think that a single +1 from any committer
>>>> (besides
>>>>> author of patch) and no -1's is sufficient to commit code.
>>>>>
>>>>> I also think we should explicitly make exceptions to these rules for
>>>>> non-code related changes (e.g. documentation). In these cases we can
>>>>>use
>>>>> lazy consensus and the committer can use their own discretion as to
>>>>>how
>>>>> long the vote should be open.
>>>>>
>>>>> 2. Releases:
>>>>> The bylaws mention a "release plan". We haven't been proposing or
>>>>>voting
>>>> on
>>>>> release plans and I don't think that's necessary as a formal process.
>>>>>I
>>>>> think any committer can propose a release at any time, something
>>>>>Taylor's
>>>>> been doing a good job of doing. Should we just remove that from the
>>>> bylaws?
>>>>>
>>>>> There was also discussion of allowing for "fast releases" for
>>>>>important
>>>>> changes that can't wait (e.g. security fixes). I am fully against
>>>>>this.
>>>>> Based on the previous discussion it sounds like we're in agreement
>>>>>that
>>>> any
>>>>> committer can make unofficial releases available publicly, and this
>>>>>is
>>>> the
>>>>> avenue we can use to get these fixes out. This way we don't commit
>>>>> ourselves to any code changes or any need to maintain backwards
>>>>> compatibility.
>>>>>
>>>>> I think the vote time for releases should be 7 days, not 3 days. A
>>>> release
>>>>> is a big deal and people need more time to test it and give feedback.
>>>> Also,
>>>>> any change to the release should require a revote. Taylor brought up
>>>>>that
>>>>> this could make getting a release out a pain and I agree. So I'm
>>>>>fine
>>>>> with including explicit exceptions in the bylaws to this rule, like
>>>>>not
>>>>> requiring a revote for changes to documentation, committer info in
>>>> pom.xml,
>>>>> etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Lastly, I want to address something that Taylor said in the previous
>>>>> discussion:
>>>>>
>>>>> 'Understood. Also be aware that lazy consensus can be invoked for
>>>>>code
>>>>> changes by declaring so in the pull request: ³I will assume lazy
>>>> consensus
>>>>> on this and commit the change in X hours if there are no -1 votes."
>>>>>
>>>>> I think Hadoop uses lazy consensus as the default, but I¹d have to
>>>> check.'
>>>>>
>>>>> I'm not sure where "be aware that lazy consensus can be invoked for
>>>>>code
>>>>> changes by declaring so in the pull request" came from. Is this a
>>>>>rule
>>>> that
>>>>> Hadoop or other Apache projects use? Ultimately each project
>>>>>determines
>>>> for
>>>>> themselves the rules for committing what Hadoop or other projects
>>>>>do
>>>> has
>>>>> no relevance on Storm. This is certainly not something we ever agreed
>>>>>to
>>>>> for the governance of Storm.
>>>>>
>>>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's
>>>> development
>>>>> has gone through some pretty ridiculous things, like the completely
>>>> broken
>>>>> record append implementation and the fiasco around the mapred.* and
>>>>> mapreduce.* namespaces. I believe Storm to be a much higher quality
>>>>>piece
>>>>> of software (though not perfect, of course) and we should try keep it
>>>> that
>>>>> way.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans
>>>>><evans@yahoo-inc.com.invalid
>>>>>
>>>>> wrote:
>>>>>
>>>>>> I have updated the proposed bylaws following Nathan and Taylor¹s
>>>>>> suggestions. They the only parts edited were the title to indicate
>>>>>>that
>>>>>> these are proposed bylaws and will not officially be adopted until
>>>>>>we
>>>> are a
>>>>>> top level project, and the voting on code changes to reflect that a
>>>>>>+1
>>>>>> from the author of the patch is not counted.
>>>>>>
>>>>>> You can find them here.
>>>>>>
>>>>>> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
>>>>>>
>>>>>> The new voting is consensus approval with (P)PMC members casting
>>>>>>binding
>>>>>> votes.
>>>>>>
>>>>>> - Bobby
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Twitter: @nathanmarz
>>>>> http://nathanmarz.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Twitter: @nathanmarz
>>> http://nathanmarz.com
>>
>
Re: [VOTE] Storm Bylaws try 2
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
How about I update the document to take into account Nathan¹s comments.
Then turn it into a formal pull request. Then we can continue the
discussion, and put more pull requests on top of it until we graduate and
have a formal vote on adoption. Then at that point we can move the bylaws
into the subversion web page repo, or add a link to the github repo for
the bylaws. Either way is fine with me.
I am canceling the vote.
- Bobby
On 6/28/14, 3:15 PM, "P. Taylor Goetz" <pt...@gmail.com> wrote:
>I agree completely!
>
>I think adding ³work in progress² or ³DRAFT² in the title will prevent
>any confusion. And maybe cancel the vote and treat it more like a patch
>for now. Then when it¹s time to formally adopt the bylaws, we can hold
>the official vote.
>
>- Taylor
>
>On Jun 28, 2014, at 2:31 PM, Nathan Marz <na...@nathanmarz.com> wrote:
>
>> My impression was that this was a vote to adopt the bylaws, since it
>>says
>> "proposed bylaws" and the vote required consensus approval.
>>
>> Regardless, I agree that we should merge it into source control and
>> collaborate on it with pull requests/comments, and we should delay a
>>vote
>> until everyone's issues have been addressed. However, let's add "work in
>> progress" to the title so people don't get confused.
>>
>>
>> On Sat, Jun 28, 2014 at 7:30 AM, P. Taylor Goetz <pt...@gmail.com>
>>wrote:
>>
>>> I¹m +1.
>>>
>>> I think with Bobby¹s latest changes it makes it abundantly clear that
>>>it
>>> is a working draft, and we are not voting to adopt them. I see this as
>>>a
>>> vote to pull the draft into source control so individual changes can be
>>> proposed and discussed as opposed to trying to approve the document in
>>>it¹s
>>> entirety.
>>>
>>> Trying to get everything right all at once places undue burden on
>>>Bobby ‹
>>> a veto forces him to cancel the vote, interpret the comments, reword
>>>things
>>> to address the comments, and initiate a new vote. Bobby was kind
>>>enough to
>>> put it together in the first place.
>>>
>>> I think it would be more efficient if we just staged it in source
>>>control
>>> (we wouldn¹t have to publish it to the website), and allow people to
>>> collaborate by proposing changes/patches that can be discussed and
>>>applied
>>> individually. Again, the document doesn¹t carry any weight until it is
>>> finalized and formally adopted.
>>>
>>>> Lastly, I want to address something that Taylor said in the previous
>>>> discussion:
>>>>
>>>> 'Understood. Also be aware that lazy consensus can be invoked for code
>>>> changes by declaring so in the pull request: ³I will assume lazy
>>> consensus
>>>> on this and commit the change in X hours if there are no -1 votes.²
>>>
>>> That should have read ³days² instead of ³hours,² so it came across a
>>> little more drastic than intended...
>>>
>>>>
>>>> I think Hadoop uses lazy consensus as the default, but I¹d have to
>>> check.'
>>>>
>>>> I'm not sure where "be aware that lazy consensus can be invoked for
>>>>code
>>>> changes by declaring so in the pull request" came from. Is this a rule
>>> that
>>>> Hadoop or other Apache projects use? Ultimately each project
>>>>determines
>>> for
>>>> themselves the rules for committing what Hadoop or other projects do
>>> has
>>>> no relevance on Storm. This is certainly not something we ever agreed
>>>>to
>>>> for the governance of Storm.
>>>
>>> That came from here [1]. But looking at it again it seems to conflict
>>>with
>>> a RTC policy (even though some projects seem to use lazy consensus with
>>> RTC). So I stand corrected.
>>>
>>> My point is that yes, other Apache projects do use lazy consensus for
>>>code
>>> changes, so it is an option that open to us if we so choose. Nothing
>>>more.
>>>
>>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's
>>> development
>>>> has gone through some pretty ridiculous things, like the completely
>>> broken
>>>> record append implementation and the fiasco around the mapred.* and
>>>> mapreduce.* namespaces. I believe Storm to be a much higher quality
>>>>piece
>>>> of software (though not perfect, of course) and we should try keep it
>>> that
>>>> way.
>>>
>>>
>>> I never meant to imply that we should aspire to be like Hadoop. I was
>>> merely using it as an example in the context of a bylaws discussion.
>>>
>>> If there¹s on goal we all share, I think it¹s to make Storm the highest
>>> quality piece of software we can. That¹s why we¹re here.
>>>
>>> No project is perfect. We will inevitably make mistakes, fix them,
>>>learn
>>> from them, and grow stronger as a community in the process.
>>>
>>> - Taylor
>>>
>>> [1] http://www.apache.org/foundation/voting.html
>>>
>>>
>>> On Jun 27, 2014, at 8:16 PM, Nathan Marz <na...@nathanmarz.com> wrote:
>>>
>>>> -1 (binding)
>>>>
>>>> I've given this quite a bit of thought, and I think we need to be more
>>>> explicit in the bylaws in a few places.
>>>>
>>>> 1. Code changes:
>>>> I've reverted a bit and think that a single +1 from any committer
>>> (besides
>>>> author of patch) and no -1's is sufficient to commit code.
>>>>
>>>> I also think we should explicitly make exceptions to these rules for
>>>> non-code related changes (e.g. documentation). In these cases we can
>>>>use
>>>> lazy consensus and the committer can use their own discretion as to
>>>>how
>>>> long the vote should be open.
>>>>
>>>> 2. Releases:
>>>> The bylaws mention a "release plan". We haven't been proposing or
>>>>voting
>>> on
>>>> release plans and I don't think that's necessary as a formal process.
>>>>I
>>>> think any committer can propose a release at any time, something
>>>>Taylor's
>>>> been doing a good job of doing. Should we just remove that from the
>>> bylaws?
>>>>
>>>> There was also discussion of allowing for "fast releases" for
>>>>important
>>>> changes that can't wait (e.g. security fixes). I am fully against
>>>>this.
>>>> Based on the previous discussion it sounds like we're in agreement
>>>>that
>>> any
>>>> committer can make unofficial releases available publicly, and this is
>>> the
>>>> avenue we can use to get these fixes out. This way we don't commit
>>>> ourselves to any code changes or any need to maintain backwards
>>>> compatibility.
>>>>
>>>> I think the vote time for releases should be 7 days, not 3 days. A
>>> release
>>>> is a big deal and people need more time to test it and give feedback.
>>> Also,
>>>> any change to the release should require a revote. Taylor brought up
>>>>that
>>>> this could make getting a release out a pain and I agree. So I'm
>>>>fine
>>>> with including explicit exceptions in the bylaws to this rule, like
>>>>not
>>>> requiring a revote for changes to documentation, committer info in
>>> pom.xml,
>>>> etc.
>>>>
>>>>
>>>>
>>>>
>>>> Lastly, I want to address something that Taylor said in the previous
>>>> discussion:
>>>>
>>>> 'Understood. Also be aware that lazy consensus can be invoked for code
>>>> changes by declaring so in the pull request: ³I will assume lazy
>>> consensus
>>>> on this and commit the change in X hours if there are no -1 votes."
>>>>
>>>> I think Hadoop uses lazy consensus as the default, but I¹d have to
>>> check.'
>>>>
>>>> I'm not sure where "be aware that lazy consensus can be invoked for
>>>>code
>>>> changes by declaring so in the pull request" came from. Is this a rule
>>> that
>>>> Hadoop or other Apache projects use? Ultimately each project
>>>>determines
>>> for
>>>> themselves the rules for committing what Hadoop or other projects do
>>> has
>>>> no relevance on Storm. This is certainly not something we ever agreed
>>>>to
>>>> for the governance of Storm.
>>>>
>>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's
>>> development
>>>> has gone through some pretty ridiculous things, like the completely
>>> broken
>>>> record append implementation and the fiasco around the mapred.* and
>>>> mapreduce.* namespaces. I believe Storm to be a much higher quality
>>>>piece
>>>> of software (though not perfect, of course) and we should try keep it
>>> that
>>>> way.
>>>>
>>>>
>>>>
>>>> On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans
>>>><evans@yahoo-inc.com.invalid
>>>>
>>>> wrote:
>>>>
>>>>> I have updated the proposed bylaws following Nathan and Taylor¹s
>>>>> suggestions. They the only parts edited were the title to indicate
>>>>>that
>>>>> these are proposed bylaws and will not officially be adopted until we
>>> are a
>>>>> top level project, and the voting on code changes to reflect that a
>>>>>+1
>>>>> from the author of the patch is not counted.
>>>>>
>>>>> You can find them here.
>>>>>
>>>>> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
>>>>>
>>>>> The new voting is consensus approval with (P)PMC members casting
>>>>>binding
>>>>> votes.
>>>>>
>>>>> - Bobby
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Twitter: @nathanmarz
>>>> http://nathanmarz.com
>>>
>>>
>>
>>
>> --
>> Twitter: @nathanmarz
>> http://nathanmarz.com
>
Re: [VOTE] Storm Bylaws try 2
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
I agree completely!
I think adding “work in progress” or “DRAFT” in the title will prevent any confusion. And maybe cancel the vote and treat it more like a patch for now. Then when it’s time to formally adopt the bylaws, we can hold the official vote.
- Taylor
On Jun 28, 2014, at 2:31 PM, Nathan Marz <na...@nathanmarz.com> wrote:
> My impression was that this was a vote to adopt the bylaws, since it says
> "proposed bylaws" and the vote required consensus approval.
>
> Regardless, I agree that we should merge it into source control and
> collaborate on it with pull requests/comments, and we should delay a vote
> until everyone's issues have been addressed. However, let's add "work in
> progress" to the title so people don't get confused.
>
>
> On Sat, Jun 28, 2014 at 7:30 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
>> I’m +1.
>>
>> I think with Bobby’s latest changes it makes it abundantly clear that it
>> is a working draft, and we are not voting to adopt them. I see this as a
>> vote to pull the draft into source control so individual changes can be
>> proposed and discussed as opposed to trying to approve the document in it’s
>> entirety.
>>
>> Trying to get everything right all at once places undue burden on Bobby —
>> a veto forces him to cancel the vote, interpret the comments, reword things
>> to address the comments, and initiate a new vote. Bobby was kind enough to
>> put it together in the first place.
>>
>> I think it would be more efficient if we just staged it in source control
>> (we wouldn’t have to publish it to the website), and allow people to
>> collaborate by proposing changes/patches that can be discussed and applied
>> individually. Again, the document doesn’t carry any weight until it is
>> finalized and formally adopted.
>>
>>> Lastly, I want to address something that Taylor said in the previous
>>> discussion:
>>>
>>> 'Understood. Also be aware that lazy consensus can be invoked for code
>>> changes by declaring so in the pull request: “I will assume lazy
>> consensus
>>> on this and commit the change in X hours if there are no -1 votes.”
>>
>> That should have read “days” instead of “hours,” so it came across a
>> little more drastic than intended...
>>
>>>
>>> I think Hadoop uses lazy consensus as the default, but I’d have to
>> check.'
>>>
>>> I'm not sure where "be aware that lazy consensus can be invoked for code
>>> changes by declaring so in the pull request" came from. Is this a rule
>> that
>>> Hadoop or other Apache projects use? Ultimately each project determines
>> for
>>> themselves the rules for committing – what Hadoop or other projects do
>> has
>>> no relevance on Storm. This is certainly not something we ever agreed to
>>> for the governance of Storm.
>>
>> That came from here [1]. But looking at it again it seems to conflict with
>> a RTC policy (even though some projects seem to use lazy consensus with
>> RTC). So I stand corrected.
>>
>> My point is that yes, other Apache projects do use lazy consensus for code
>> changes, so it is an option that open to us if we so choose. Nothing more.
>>
>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's
>> development
>>> has gone through some pretty ridiculous things, like the completely
>> broken
>>> record append implementation and the fiasco around the mapred.* and
>>> mapreduce.* namespaces. I believe Storm to be a much higher quality piece
>>> of software (though not perfect, of course) and we should try keep it
>> that
>>> way.
>>
>>
>> I never meant to imply that we should aspire to be like Hadoop. I was
>> merely using it as an example in the context of a bylaws discussion.
>>
>> If there’s on goal we all share, I think it’s to make Storm the highest
>> quality piece of software we can. That’s why we’re here.
>>
>> No project is perfect. We will inevitably make mistakes, fix them, learn
>> from them, and grow stronger as a community in the process.
>>
>> - Taylor
>>
>> [1] http://www.apache.org/foundation/voting.html
>>
>>
>> On Jun 27, 2014, at 8:16 PM, Nathan Marz <na...@nathanmarz.com> wrote:
>>
>>> -1 (binding)
>>>
>>> I've given this quite a bit of thought, and I think we need to be more
>>> explicit in the bylaws in a few places.
>>>
>>> 1. Code changes:
>>> I've reverted a bit and think that a single +1 from any committer
>> (besides
>>> author of patch) and no -1's is sufficient to commit code.
>>>
>>> I also think we should explicitly make exceptions to these rules for
>>> non-code related changes (e.g. documentation). In these cases we can use
>>> lazy consensus and the committer can use their own discretion as to how
>>> long the vote should be open.
>>>
>>> 2. Releases:
>>> The bylaws mention a "release plan". We haven't been proposing or voting
>> on
>>> release plans and I don't think that's necessary as a formal process. I
>>> think any committer can propose a release at any time, something Taylor's
>>> been doing a good job of doing. Should we just remove that from the
>> bylaws?
>>>
>>> There was also discussion of allowing for "fast releases" for important
>>> changes that can't wait (e.g. security fixes). I am fully against this.
>>> Based on the previous discussion it sounds like we're in agreement that
>> any
>>> committer can make unofficial releases available publicly, and this is
>> the
>>> avenue we can use to get these fixes out. This way we don't commit
>>> ourselves to any code changes or any need to maintain backwards
>>> compatibility.
>>>
>>> I think the vote time for releases should be 7 days, not 3 days. A
>> release
>>> is a big deal and people need more time to test it and give feedback.
>> Also,
>>> any change to the release should require a revote. Taylor brought up that
>>> this could make getting a release out a pain – and I agree. So I'm fine
>>> with including explicit exceptions in the bylaws to this rule, like not
>>> requiring a revote for changes to documentation, committer info in
>> pom.xml,
>>> etc.
>>>
>>>
>>>
>>>
>>> Lastly, I want to address something that Taylor said in the previous
>>> discussion:
>>>
>>> 'Understood. Also be aware that lazy consensus can be invoked for code
>>> changes by declaring so in the pull request: “I will assume lazy
>> consensus
>>> on this and commit the change in X hours if there are no -1 votes."
>>>
>>> I think Hadoop uses lazy consensus as the default, but I’d have to
>> check.'
>>>
>>> I'm not sure where "be aware that lazy consensus can be invoked for code
>>> changes by declaring so in the pull request" came from. Is this a rule
>> that
>>> Hadoop or other Apache projects use? Ultimately each project determines
>> for
>>> themselves the rules for committing – what Hadoop or other projects do
>> has
>>> no relevance on Storm. This is certainly not something we ever agreed to
>>> for the governance of Storm.
>>>
>>> Finally, we should not be aspiring to be like Hadoop. Hadoop's
>> development
>>> has gone through some pretty ridiculous things, like the completely
>> broken
>>> record append implementation and the fiasco around the mapred.* and
>>> mapreduce.* namespaces. I believe Storm to be a much higher quality piece
>>> of software (though not perfect, of course) and we should try keep it
>> that
>>> way.
>>>
>>>
>>>
>>> On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans <evans@yahoo-inc.com.invalid
>>>
>>> wrote:
>>>
>>>> I have updated the proposed bylaws following Nathan and Taylor’s
>>>> suggestions. They the only parts edited were the title to indicate that
>>>> these are proposed bylaws and will not officially be adopted until we
>> are a
>>>> top level project, and the voting on code changes to reflect that a +1
>>>> from the author of the patch is not counted.
>>>>
>>>> You can find them here.
>>>>
>>>> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
>>>>
>>>> The new voting is consensus approval with (P)PMC members casting binding
>>>> votes.
>>>>
>>>> - Bobby
>>>>
>>>
>>>
>>>
>>> --
>>> Twitter: @nathanmarz
>>> http://nathanmarz.com
>>
>>
>
>
> --
> Twitter: @nathanmarz
> http://nathanmarz.com
Re: [VOTE] Storm Bylaws try 2
Posted by Nathan Marz <na...@nathanmarz.com>.
My impression was that this was a vote to adopt the bylaws, since it says
"proposed bylaws" and the vote required consensus approval.
Regardless, I agree that we should merge it into source control and
collaborate on it with pull requests/comments, and we should delay a vote
until everyone's issues have been addressed. However, let's add "work in
progress" to the title so people don't get confused.
On Sat, Jun 28, 2014 at 7:30 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
> I’m +1.
>
> I think with Bobby’s latest changes it makes it abundantly clear that it
> is a working draft, and we are not voting to adopt them. I see this as a
> vote to pull the draft into source control so individual changes can be
> proposed and discussed as opposed to trying to approve the document in it’s
> entirety.
>
> Trying to get everything right all at once places undue burden on Bobby —
> a veto forces him to cancel the vote, interpret the comments, reword things
> to address the comments, and initiate a new vote. Bobby was kind enough to
> put it together in the first place.
>
> I think it would be more efficient if we just staged it in source control
> (we wouldn’t have to publish it to the website), and allow people to
> collaborate by proposing changes/patches that can be discussed and applied
> individually. Again, the document doesn’t carry any weight until it is
> finalized and formally adopted.
>
> > Lastly, I want to address something that Taylor said in the previous
> > discussion:
> >
> > 'Understood. Also be aware that lazy consensus can be invoked for code
> > changes by declaring so in the pull request: “I will assume lazy
> consensus
> > on this and commit the change in X hours if there are no -1 votes.”
>
> That should have read “days” instead of “hours,” so it came across a
> little more drastic than intended...
>
> >
> > I think Hadoop uses lazy consensus as the default, but I’d have to
> check.'
> >
> > I'm not sure where "be aware that lazy consensus can be invoked for code
> > changes by declaring so in the pull request" came from. Is this a rule
> that
> > Hadoop or other Apache projects use? Ultimately each project determines
> for
> > themselves the rules for committing – what Hadoop or other projects do
> has
> > no relevance on Storm. This is certainly not something we ever agreed to
> > for the governance of Storm.
>
> That came from here [1]. But looking at it again it seems to conflict with
> a RTC policy (even though some projects seem to use lazy consensus with
> RTC). So I stand corrected.
>
> My point is that yes, other Apache projects do use lazy consensus for code
> changes, so it is an option that open to us if we so choose. Nothing more.
>
> > Finally, we should not be aspiring to be like Hadoop. Hadoop's
> development
> > has gone through some pretty ridiculous things, like the completely
> broken
> > record append implementation and the fiasco around the mapred.* and
> > mapreduce.* namespaces. I believe Storm to be a much higher quality piece
> > of software (though not perfect, of course) and we should try keep it
> that
> > way.
>
>
> I never meant to imply that we should aspire to be like Hadoop. I was
> merely using it as an example in the context of a bylaws discussion.
>
> If there’s on goal we all share, I think it’s to make Storm the highest
> quality piece of software we can. That’s why we’re here.
>
> No project is perfect. We will inevitably make mistakes, fix them, learn
> from them, and grow stronger as a community in the process.
>
> - Taylor
>
> [1] http://www.apache.org/foundation/voting.html
>
>
> On Jun 27, 2014, at 8:16 PM, Nathan Marz <na...@nathanmarz.com> wrote:
>
> > -1 (binding)
> >
> > I've given this quite a bit of thought, and I think we need to be more
> > explicit in the bylaws in a few places.
> >
> > 1. Code changes:
> > I've reverted a bit and think that a single +1 from any committer
> (besides
> > author of patch) and no -1's is sufficient to commit code.
> >
> > I also think we should explicitly make exceptions to these rules for
> > non-code related changes (e.g. documentation). In these cases we can use
> > lazy consensus and the committer can use their own discretion as to how
> > long the vote should be open.
> >
> > 2. Releases:
> > The bylaws mention a "release plan". We haven't been proposing or voting
> on
> > release plans and I don't think that's necessary as a formal process. I
> > think any committer can propose a release at any time, something Taylor's
> > been doing a good job of doing. Should we just remove that from the
> bylaws?
> >
> > There was also discussion of allowing for "fast releases" for important
> > changes that can't wait (e.g. security fixes). I am fully against this.
> > Based on the previous discussion it sounds like we're in agreement that
> any
> > committer can make unofficial releases available publicly, and this is
> the
> > avenue we can use to get these fixes out. This way we don't commit
> > ourselves to any code changes or any need to maintain backwards
> > compatibility.
> >
> > I think the vote time for releases should be 7 days, not 3 days. A
> release
> > is a big deal and people need more time to test it and give feedback.
> Also,
> > any change to the release should require a revote. Taylor brought up that
> > this could make getting a release out a pain – and I agree. So I'm fine
> > with including explicit exceptions in the bylaws to this rule, like not
> > requiring a revote for changes to documentation, committer info in
> pom.xml,
> > etc.
> >
> >
> >
> >
> > Lastly, I want to address something that Taylor said in the previous
> > discussion:
> >
> > 'Understood. Also be aware that lazy consensus can be invoked for code
> > changes by declaring so in the pull request: “I will assume lazy
> consensus
> > on this and commit the change in X hours if there are no -1 votes."
> >
> > I think Hadoop uses lazy consensus as the default, but I’d have to
> check.'
> >
> > I'm not sure where "be aware that lazy consensus can be invoked for code
> > changes by declaring so in the pull request" came from. Is this a rule
> that
> > Hadoop or other Apache projects use? Ultimately each project determines
> for
> > themselves the rules for committing – what Hadoop or other projects do
> has
> > no relevance on Storm. This is certainly not something we ever agreed to
> > for the governance of Storm.
> >
> > Finally, we should not be aspiring to be like Hadoop. Hadoop's
> development
> > has gone through some pretty ridiculous things, like the completely
> broken
> > record append implementation and the fiasco around the mapred.* and
> > mapreduce.* namespaces. I believe Storm to be a much higher quality piece
> > of software (though not perfect, of course) and we should try keep it
> that
> > way.
> >
> >
> >
> > On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans <evans@yahoo-inc.com.invalid
> >
> > wrote:
> >
> >> I have updated the proposed bylaws following Nathan and Taylor’s
> >> suggestions. They the only parts edited were the title to indicate that
> >> these are proposed bylaws and will not officially be adopted until we
> are a
> >> top level project, and the voting on code changes to reflect that a +1
> >> from the author of the patch is not counted.
> >>
> >> You can find them here.
> >>
> >> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
> >>
> >> The new voting is consensus approval with (P)PMC members casting binding
> >> votes.
> >>
> >> - Bobby
> >>
> >
> >
> >
> > --
> > Twitter: @nathanmarz
> > http://nathanmarz.com
>
>
--
Twitter: @nathanmarz
http://nathanmarz.com
Re: [VOTE] Storm Bylaws try 2
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
I’m +1.
I think with Bobby’s latest changes it makes it abundantly clear that it is a working draft, and we are not voting to adopt them. I see this as a vote to pull the draft into source control so individual changes can be proposed and discussed as opposed to trying to approve the document in it’s entirety.
Trying to get everything right all at once places undue burden on Bobby — a veto forces him to cancel the vote, interpret the comments, reword things to address the comments, and initiate a new vote. Bobby was kind enough to put it together in the first place.
I think it would be more efficient if we just staged it in source control (we wouldn’t have to publish it to the website), and allow people to collaborate by proposing changes/patches that can be discussed and applied individually. Again, the document doesn’t carry any weight until it is finalized and formally adopted.
> Lastly, I want to address something that Taylor said in the previous
> discussion:
>
> 'Understood. Also be aware that lazy consensus can be invoked for code
> changes by declaring so in the pull request: “I will assume lazy consensus
> on this and commit the change in X hours if there are no -1 votes.”
That should have read “days” instead of “hours,” so it came across a little more drastic than intended...
>
> I think Hadoop uses lazy consensus as the default, but I’d have to check.'
>
> I'm not sure where "be aware that lazy consensus can be invoked for code
> changes by declaring so in the pull request" came from. Is this a rule that
> Hadoop or other Apache projects use? Ultimately each project determines for
> themselves the rules for committing – what Hadoop or other projects do has
> no relevance on Storm. This is certainly not something we ever agreed to
> for the governance of Storm.
That came from here [1]. But looking at it again it seems to conflict with a RTC policy (even though some projects seem to use lazy consensus with RTC). So I stand corrected.
My point is that yes, other Apache projects do use lazy consensus for code changes, so it is an option that open to us if we so choose. Nothing more.
> Finally, we should not be aspiring to be like Hadoop. Hadoop's development
> has gone through some pretty ridiculous things, like the completely broken
> record append implementation and the fiasco around the mapred.* and
> mapreduce.* namespaces. I believe Storm to be a much higher quality piece
> of software (though not perfect, of course) and we should try keep it that
> way.
I never meant to imply that we should aspire to be like Hadoop. I was merely using it as an example in the context of a bylaws discussion.
If there’s on goal we all share, I think it’s to make Storm the highest quality piece of software we can. That’s why we’re here.
No project is perfect. We will inevitably make mistakes, fix them, learn from them, and grow stronger as a community in the process.
- Taylor
[1] http://www.apache.org/foundation/voting.html
On Jun 27, 2014, at 8:16 PM, Nathan Marz <na...@nathanmarz.com> wrote:
> -1 (binding)
>
> I've given this quite a bit of thought, and I think we need to be more
> explicit in the bylaws in a few places.
>
> 1. Code changes:
> I've reverted a bit and think that a single +1 from any committer (besides
> author of patch) and no -1's is sufficient to commit code.
>
> I also think we should explicitly make exceptions to these rules for
> non-code related changes (e.g. documentation). In these cases we can use
> lazy consensus and the committer can use their own discretion as to how
> long the vote should be open.
>
> 2. Releases:
> The bylaws mention a "release plan". We haven't been proposing or voting on
> release plans and I don't think that's necessary as a formal process. I
> think any committer can propose a release at any time, something Taylor's
> been doing a good job of doing. Should we just remove that from the bylaws?
>
> There was also discussion of allowing for "fast releases" for important
> changes that can't wait (e.g. security fixes). I am fully against this.
> Based on the previous discussion it sounds like we're in agreement that any
> committer can make unofficial releases available publicly, and this is the
> avenue we can use to get these fixes out. This way we don't commit
> ourselves to any code changes or any need to maintain backwards
> compatibility.
>
> I think the vote time for releases should be 7 days, not 3 days. A release
> is a big deal and people need more time to test it and give feedback. Also,
> any change to the release should require a revote. Taylor brought up that
> this could make getting a release out a pain – and I agree. So I'm fine
> with including explicit exceptions in the bylaws to this rule, like not
> requiring a revote for changes to documentation, committer info in pom.xml,
> etc.
>
>
>
>
> Lastly, I want to address something that Taylor said in the previous
> discussion:
>
> 'Understood. Also be aware that lazy consensus can be invoked for code
> changes by declaring so in the pull request: “I will assume lazy consensus
> on this and commit the change in X hours if there are no -1 votes."
>
> I think Hadoop uses lazy consensus as the default, but I’d have to check.'
>
> I'm not sure where "be aware that lazy consensus can be invoked for code
> changes by declaring so in the pull request" came from. Is this a rule that
> Hadoop or other Apache projects use? Ultimately each project determines for
> themselves the rules for committing – what Hadoop or other projects do has
> no relevance on Storm. This is certainly not something we ever agreed to
> for the governance of Storm.
>
> Finally, we should not be aspiring to be like Hadoop. Hadoop's development
> has gone through some pretty ridiculous things, like the completely broken
> record append implementation and the fiasco around the mapred.* and
> mapreduce.* namespaces. I believe Storm to be a much higher quality piece
> of software (though not perfect, of course) and we should try keep it that
> way.
>
>
>
> On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans <ev...@yahoo-inc.com.invalid>
> wrote:
>
>> I have updated the proposed bylaws following Nathan and Taylor’s
>> suggestions. They the only parts edited were the title to indicate that
>> these are proposed bylaws and will not officially be adopted until we are a
>> top level project, and the voting on code changes to reflect that a +1
>> from the author of the patch is not counted.
>>
>> You can find them here.
>>
>> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
>>
>> The new voting is consensus approval with (P)PMC members casting binding
>> votes.
>>
>> - Bobby
>>
>
>
>
> --
> Twitter: @nathanmarz
> http://nathanmarz.com
Re: [VOTE] Storm Bylaws try 2
Posted by Nathan Marz <na...@nathanmarz.com>.
-1 (binding)
I've given this quite a bit of thought, and I think we need to be more
explicit in the bylaws in a few places.
1. Code changes:
I've reverted a bit and think that a single +1 from any committer (besides
author of patch) and no -1's is sufficient to commit code.
I also think we should explicitly make exceptions to these rules for
non-code related changes (e.g. documentation). In these cases we can use
lazy consensus and the committer can use their own discretion as to how
long the vote should be open.
2. Releases:
The bylaws mention a "release plan". We haven't been proposing or voting on
release plans and I don't think that's necessary as a formal process. I
think any committer can propose a release at any time, something Taylor's
been doing a good job of doing. Should we just remove that from the bylaws?
There was also discussion of allowing for "fast releases" for important
changes that can't wait (e.g. security fixes). I am fully against this.
Based on the previous discussion it sounds like we're in agreement that any
committer can make unofficial releases available publicly, and this is the
avenue we can use to get these fixes out. This way we don't commit
ourselves to any code changes or any need to maintain backwards
compatibility.
I think the vote time for releases should be 7 days, not 3 days. A release
is a big deal and people need more time to test it and give feedback. Also,
any change to the release should require a revote. Taylor brought up that
this could make getting a release out a pain – and I agree. So I'm fine
with including explicit exceptions in the bylaws to this rule, like not
requiring a revote for changes to documentation, committer info in pom.xml,
etc.
Lastly, I want to address something that Taylor said in the previous
discussion:
'Understood. Also be aware that lazy consensus can be invoked for code
changes by declaring so in the pull request: “I will assume lazy consensus
on this and commit the change in X hours if there are no -1 votes."
I think Hadoop uses lazy consensus as the default, but I’d have to check.'
I'm not sure where "be aware that lazy consensus can be invoked for code
changes by declaring so in the pull request" came from. Is this a rule that
Hadoop or other Apache projects use? Ultimately each project determines for
themselves the rules for committing – what Hadoop or other projects do has
no relevance on Storm. This is certainly not something we ever agreed to
for the governance of Storm.
Finally, we should not be aspiring to be like Hadoop. Hadoop's development
has gone through some pretty ridiculous things, like the completely broken
record append implementation and the fiasco around the mapred.* and
mapreduce.* namespaces. I believe Storm to be a much higher quality piece
of software (though not perfect, of course) and we should try keep it that
way.
On Thu, Jun 26, 2014 at 8:56 AM, Bobby Evans <ev...@yahoo-inc.com.invalid>
wrote:
> I have updated the proposed bylaws following Nathan and Taylor’s
> suggestions. They the only parts edited were the title to indicate that
> these are proposed bylaws and will not officially be adopted until we are a
> top level project, and the voting on code changes to reflect that a +1
> from the author of the patch is not counted.
>
> You can find them here.
>
> https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
>
> The new voting is consensus approval with (P)PMC members casting binding
> votes.
>
> - Bobby
>
--
Twitter: @nathanmarz
http://nathanmarz.com
Re: [VOTE] Storm Bylaws try 2
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
Sorry forgot to mention that the voting will be open for 1 week, and will
close Thursday July 3rd. Also anyone in the community is encouraged to
vote, even if your vote is not binding. This helps us all know how the
community feels.
- Bobby
On 6/26/14, 10:56 AM, "Bobby Evans" <ev...@yahoo-inc.com.INVALID> wrote:
>I have updated the proposed bylaws following Nathan and Taylor¹s
>suggestions. They the only parts edited were the title to indicate that
>these are proposed bylaws and will not officially be adopted until we are
>a top level project, and the voting on code changes to reflect that a +1
>from the author of the patch is not counted.
>
>You can find them here.
>
>https://github.com/revans2/incubator-storm/blob/bylaws/BYLAWS.md
>
>The new voting is consensus approval with (P)PMC members casting binding
>votes.
>
>- Bobby