Other projects do seem to have access. See example of Mesos: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=1
Perhaps, it is only available to TLPs? It gives a good way to prioritize backlog, organize work into sprints, Kanban view of who's working on what, etc. No biggie; the first release can be managed without it using old-school RAIL (Rolling Action Item List) :) William has already created a Release Page (draft) here: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453 Just have to create tasks with respective owners and a timeline. Does the group suggest we have a standing 30 minute meeting weekly or just interact via mailing list and JIRAs? More to come... Nitin ________________________________________ From: Anthony Baker <[email protected]> Sent: Monday, September 14, 2015 9:41 AM To: [email protected] Subject: Re: Releasing Geode (was Re: September 2015 Report) What do we get from the Scrum Board? How are other ASF projects tracking release activities? Anthony > On Sep 14, 2015, at 9:27 AM, Kirk Lund <[email protected]> wrote: > > I thought Jira Scrum Board is an Atlassian add-on that might not be > available on the ASF Jira. Ask Roman or INFRA if it's available to us. > > -Kirk > > > On Mon, Sep 14, 2015 at 7:44 AM, William Markito <[email protected]> > wrote: > >> I've tried a similar thing in the past Nitin and looks it's something you >> may need to ask INFRA about.... Even with admin permissions on the project >> it didn't work. >> >> On Fri, Sep 11, 2015 at 5:11 PM, Nitin Lamba <[email protected]> wrote: >> >>> Seems I'm having trouble creating Scrum Board for the project. Thought I >>> was given the right JIRA permissions. >>> >>> Is there a way to check if the project is 'allowed' to use the Agile >>> plugin? >>> >>> Thanks, >>> Nitin >>> >>> ________________________________________ >>> From: Kirk Lund <[email protected]> >>> Sent: Friday, September 11, 2015 11:24 AM >>> To: [email protected] >>> Subject: Re: Releasing Geode (was Re: September 2015 Report) >>> >>> I'll file the ticket to rename gemfire-junit to gemfire-common and create >>> the annotation. >>> >>> -Kirk >>> >>> On Friday, September 11, 2015, 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] >>> <javascript:;>> >>>> 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] >>>> <javascript:;>> 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] <javascript:;>> >>>>>> Sent: Thursday, September 10, 2015 8:41 PM >>>>>> To: [email protected] <javascript:;> >>>>>> Cc: [email protected] <javascript:;> >>>>>> 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] >>>> <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. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>> >> >> >> >> -- >> >> William Markito Oliveira >> Enterprise Architect >> -- For questions about Apache Geode, please write to >> *[email protected] >> <[email protected]>* >>
