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.
>
>

Reply via email to