First off – it doesn't make sense to use the voting rules in the bylaws
we're voting on as we haven't adopted the bylaws yet. I think that forming
the initial set of bylaws should require consensus approval. We don't have
that many PPMC members that this is going to hold us back, and I think it's
important that we're all in complete agreement on the bylaws moving
forward. Obviously if we agree to this set of bylaws than future changes
can be accomplished with lazy 2/3 majority.

A few things:

- Code changes should be two +1's from committers other than the one who
authored the patch, and no -1's. I don't think a case where only a single
+1 is needed to get a change committed allows for sufficient review. This
is also the rule we all agreed to in the move to Apache and also before.

- I think keeping the roles of PMC member and committer separate in the
bylaws is fine. I can see how having a PMC that's too big could slow down a
project, so I can see how we'll reach a point where we'll want to propose
people as committers and not PMC members. I don't think having this
distinction in the bylaws in any way slows down the project, as we can just
propose people to be both committers and PMC members as we have been all
along.

- It's true that there are certain cases where we'd want to get changes in
quickly (e.g. security fix). However, making mechanisms for getting things
in quickly would also make it possible to get things in that haven't been
sufficiently reviewed and could be detrimental to the project. An
alternative is to not change any of the processes for making official Storm
releases, and instead make alternative pathways to make "unofficial"
releases based on work that hasn't been fully vetted through the normal
process.  These releases would have the caveat that whatever is in them
could change or be removed in a future release. This way we can get things
out to the community quickly if need be, but make sure that nothing gets
into a permanent release that hasn't been properly vetted. The process for
"emergency release" could be something like lazy consensus over a 1 day
vote, or maybe one +1 and no -1's over a 1 day vote. Those releases would
be tagged something like 0.9.2-hotfix1, and an emergency release would be
followed by a normal vote as to whether to do an official release with
those changes.

- I do not think we should try to make a distinction between "minor"
changes to a release and "normal" changes that do or do not require a
re-vote. How are we really going to come up with a definition of "minor"
that's not ambiguous? I don't see there being any rush to getting releases
out a couple days earlier, and I view it as far more important to ensure
that sufficient review is done such that we don't release something bad to
the community. Even "minor" changes can go horribly wrong, as I'm sure
we've all experienced before. So everything should be properly vetted and
any changes should require a re-vote. As stated in the prior point I think
we can have separate pathways for "emergency" releases that are distinct
from normal releases.



On Fri, Jun 20, 2014 at 10:16 AM, Andy Feng <[email protected]> wrote:

> +1
>
> On 6/20/14, 6:05 AM, "Bobby Evans" <[email protected]> wrote:
>
> >I got almost no feedback on the bylaws. I am hoping everyone thought they
> >were a good idea and not that the document was so long that few bothered
> >to
> >read it.   Either way I am calling a vote on the bylaws.
> >
> >In accordance with the proposed bylaws the vote will run for 7 days ending
> >Friday June 27th, and will require at least 3 +1s from active (P)PMC
> >members with at least twice as many +1s as -1s.  Others in the community
> >are encouraged to vote as well to let your opinion be known, even if your
> >vote is not binding.
> >
> >If the vote passes I'll update the storm web page to include the bylaws.
> >I
> >am +1 (binding)
> >
> >You can find the markdown formatted bylaws at
> >
> >
> https://github.com/revans2/incubator-storm/blob/84d297a23c05fef5164029bd4b
> >697071aa349f9c/BYLAWS.md
> >
> >I only updated the formatting from the original proposal as you can see
> >here
> >
> >
> https://github.com/revans2/incubator-storm/commit/84d297a23c05fef5164029bd
> >4b697071aa349f9c#diff-77abd199a39cb67711132cd27fe41f6b
> >
> >- Bobby
>
>
>


-- 
Twitter: @nathanmarz
http://nathanmarz.com

Reply via email to