+1 for having Nitin as release manager I also really like Kirks suggestion of marking some new APIs as experimental. How about using an @Incubating annotation that shows up in the javadocs?
-Dan On Thu, Sep 10, 2015 at 10:14 PM, Nitin Lamba <[email protected]> wrote: > Great suggestions Anthony! > > For starters, can I get PM rights in Geode JIRA? I should then be able to > make these changes fairly quickly. Also, it may make sense to create an > Agile board to prioritize the issues we need to get done for the first > release. There are a lot of little tasks that we should start capturing... > > Best, > Nitin > > ________________________________________ > From: Anthony Baker <[email protected]> > Sent: Thursday, September 10, 2015 8:41 PM > To: [email protected] > Cc: [email protected] > Subject: Re: Releasing Geode (was Re: September 2015 Report) > > 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]> 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]<mailto:[email protected] > >> > > Sent: Thursday, September 10, 2015 3:42 PM > > Subject: Re: Releasing Geode (was Re: September 2015 Report) > > To: <[email protected]<mailto:[email protected]>>, < > [email protected]<mailto:[email protected]>> > > > > > > On Thu, Sep 10, 2015 at 10:01 AM, Ashvin A <[email protected]<mailto: > [email protected]>> 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. > > > > > >
