+1 from me as well
05.07.2017, 15:59, "David Lyle" <[email protected]>: > +1 on all. Sensible and much welcome changes. > > Thanks, > > -D... > > 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 ------------------- Thank you, James Sirota PPMC- Apache Metron (Incubating) jsirota AT apache DOT org
