Vote passes with +1 : 4 votes (3 binding, 1 non-binding) 0 : none -1 : none
I’ll edit the doc to reflect the change. Thanks, --Matt On 7/6/17, 10:53 AM, "Matt Foley" <[email protected] on behalf of [email protected]> wrote: Thanks, all. That’s 3 binding +1’s, so I’m going to proceed with METRON-1021. Vote needs to stay open 72 hours tho, so if anyone else wishes to vote pro or con, you’ll be listened to. Thanks, --Matt On 7/6/17, 10:24 AM, "Nick Allen" <[email protected]> wrote: +1 I think that makes a lot of sense. On Wed, Jul 5, 2017 at 5:47 PM, Matt Foley <[email protected]> wrote: > (The below proposal is also stated in https://issues.apache.org/ > jira/browse/METRON-1020 ) > > The following proposed changes are small, but not just editorial in > nature, hence will require vote of the community to change. Our bylaws > don’t have an action type of Modifying Policy, but it’s probably fair to > consider policies to be “included by reference” in Bylaws, so let’s vote on > this like a Bylaws change. “Lazy majority of PMC members” applies – same > as a release. > > Regarding the process at https://cwiki.apache.org/ > confluence/display/METRON/Release+Process : > > 1. Add a step to tag the final release, as "apache-metron-<finalversion>- > release". > > 2. The current policy says that when a critical release is urgently > needed, "the 72 hour waiting periods in Steps 7 and 8 can be waived." The > formerly referenced Step 8 was for the Incubator vote, so that can be > removed as an editorial issue, but we should also allow for not waiting for > mirror propagation – let the mirrors catch up as fast as they can. So the > text should now read: "the 72 hour waiting period in Step 7 and the wait > for mirror propagation in Step 10 can be waived." > > 3. Finally, it is good practice to increment the build version in POMs > immediately AFTER a release, so that builds with new stuff cannot be > mistaken for builds of the release version. The current policy says to > increment it just BEFORE a release. I suggest changing this to say: > a) immediately after a release, increment the MINOR version number (eg, > with the 0.4.0 just released, set the new version number to 0.4.1) > b) immediately before a release, decide whether it will be a minor or > major release. If minor, assure that the minor version number was already > incremented after the last release and continue to use that number. If > major, change the version number to the desired new major version. > c) These version number changes are in master branch. Creation of new > branches does not occur until the idea of creating a maintenance branch or > a new release branch has been consented by the community. > > Please share your thoughts and/or vote. > Thanks, > --Matt > > >
