+1 for having Nitin as RM and for Anthony's list (with the addition below) Any new APIs that are half-baked need cleanup if there's any chance we'll be locked in with them for backwards compatibility... or we have to remove the new API or otherwise mark it as experimental in someway.
-Kirk On Thursday, September 10, 2015, Anthony Baker <[email protected]> wrote: > Thanks for jumping in Nitin! I suggest we: > > 1) Rename the JIRA version from 1.0.0-incubating to > 1.0.0-incubating-alpha1. > 2) Update the versionNumber property in gradle.properties accordingly > (note: this may have downstream effects on other projects like > SpringDataGemFire). > 3) Agree on the remaining issues to be included in the alpha1 release > (GEODE-77/18). > > GEODE-77 seems to be progressing nicely. GEODE-18 (license headers) has > been stalled out for awhile after some great initial work by Niall. > > Current release notes: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12332343 > < > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12332343 > > > > We should probably go through the API additions that are still in-progress > and identify/annotate experimental features. Thoughts? > > Anthony > > > > > On Sep 10, 2015, at 7:13 PM, Nitin Lamba <[email protected] <javascript:;>> > wrote: > > > > > > Thanks Roman and Greg for the opportunity/ challenge! Happy to help with > the initial release if the group agrees to it, and with your guidance/ > support, of course. > > When do we start!? > > Best, > > Nitin > > _____________________________ > > From: Roman Shaposhnik <[email protected] <javascript:;><mailto: > [email protected] <javascript:;>>> > > Sent: Thursday, September 10, 2015 3:42 PM > > Subject: Re: Releasing Geode (was Re: September 2015 Report) > > To: <[email protected] <javascript:;><mailto:[email protected] > <javascript:;>>>, <[email protected] <javascript:;><mailto: > [email protected] <javascript:;>>> > > > > > > On Thu, Sep 10, 2015 at 10:01 AM, Ashvin A <[email protected] > <javascript:;><mailto:[email protected] <javascript:;>>> wrote: > >> http://www.apache.org/dev/release-publishing.html#release_manager > >> > >> *"The common practice at Apache is for a single individual to take > >> responsibility for the mechanics of a release. That individual is called > >> the 'release manager.' Release managers take care of shepherding a > release > >> from an initial community consensus to make it to final > >> distribution.Release managers do the work of pushing out releases. > However, > >> release managers are not ultimately responsible. The PMC in general, and > >> the PMC chair in particular (as an officer of the Foundation) is > >> responsible for compliance with requirements.Any committer may serve as > the > >> manager of a release.A release starts when the project community agrees > to > >> make a release. However, no release manager can make a valid release > unless > >> the community has taken the necessary steps to prepare in advance. The > >> source code and build process must comply with the legal and > intellectual > >> property requirements for a valid release, and the project must have the > >> infrastructure in place to correctly sign the release artifacts."* > >> > >> > >> Is it important to be a committer to be a release manager? > > > > Somewhat, but it is much more important for a TLP. But even there I was > an RM > > for a Hadoop release before I was a committer on the project. > > > > Literally the only thing you can't do as an RM if you are NOT a > committer on the > > project is cherry-picking commits into a release branch. But you know > what? This > > is a bad practice anyway. This is something that appropriate original > commiter > > should be doing instead (which makes RM a bit more of a cat herder, but > that's > > ok ;-)). > > > > Thanks, > > Roman. > > > > > >
