Maybe we should consider canceling this vote and re-wording it a bit. The graduation resolution template implies that bylaws are adopted during graduation:
> RESOLVED, that the initial Apache ${PROJECT} PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache ${PROJECT} Project; and be it further
Even though Bobby specifically mentioned adopting the bylaws, that’s not really
how I looked at this proposal. I see it more as a proposal to pull the document
Bobby put together into source control as a working draft so we can track
changes, and vote on proposed changes as we move toward graduation (when we
would formally adopt the final draft). If this is the approach we decide to
take, it would probably be best to add a prominent header identifying the
document as a WORKING DRAFT.
See additional comments in-line below.
- Taylor
On Jun 20, 2014, at 3:29 PM, Nathan Marz <[email protected]> wrote:
> 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.
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.
Remember too that all our code is under source control and any mistaken or
misguided commit can easily be rolled back.
>
> - 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.
Agreed. Lets keep them separate and continue using the committer+PPMC member
convention when proposing new members. We can decide later, or on a
case-by-case basis if we want to deviate from this convention.
>
> - 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.
>
We’re pretty much already doing lot of this today. For example with the
security branch I periodically make builds available via my people.a.o account
for convenience. Obviously they are not official releases and do not get
distributed through dist.a.o. We can do this at any time.
Also remember that when we vote on releases, we’re really just voting on a
release *candidate*. The votes can always be cancelled and/or vetoed and a new
release candidate/vote issued. Only when an RC has been officially approved can
artifacts be released through official channels.
> - 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.
I mainly consider “minor” changes from a release management perspective —
changes that do not alter any source code (.java, .clj, .js, .py, etc.).
Real-world examples of “minor” changes:
- updating CHANGELOG.md when merging pull requests.
- adding new committer information to the parent pom.xml.
- updating the maven-release-plugin to 2.5 to fix an issue that prevented the
plugin from properly creating a release.
- rolling back a botched release attempt (resetting version numbers in poms,
deleting tags, etc.)
- fixing links in the README that pointed to the old wiki
- updating the contributor list
All of these require git commits. None of them alter the runtime
characteristics of the software. If we required a 2+ day approval for these
things our daily/release workflow would grind to a halt.
See also my previous comment about rolling back wayward changes. If things go
horribly wrong, the change that caused it can be reverted.
Finally, the release DISCUSS and VOTE threads are the final protection from
releasing something bad to the community. As such, I would hope that all
committers do their best to participate in the discussions and help vet
everything that goes into a release.
>
>
>
> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
