+1 to @Experimental There are some open bugs related to HdfsStore API. HdfsStore APIs could be categorized as @Experimental for Alpha-1 release.
On Fri, Sep 11, 2015 at 9:35 AM, Anthony Baker <[email protected]> wrote: > @Experimental seems to be more common (spark, rxjava, jgroups, ). > > I would rename the gemfire-junit module to gemfire-common and put the > annotation there. > > Anthony > > > > On Sep 11, 2015, at 9:26 AM, Dan Smith <[email protected]> wrote: > > > > +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. > >>> > >>> > >> > >> > >
