Folks I have updated the 4.3 release page [1] with a section on Release Management that has a table for Role and Volunteers. So far Frankie and Travis have stepped up for documentation. If you plan to volunteer for specific roles please reply to this thread and put your name and email on the Release wiki page
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.3+Release > -----Original Message----- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: Friday, October 11, 2013 5:39 PM > To: dev@cloudstack.apache.org > Cc: fran...@angani.co; Jonathan Creasy (jonathan.cre...@contegix.com) > Subject: RE: [ACS43] [DISCUSS] Release management tasks up for grabs > > Travis thanks for your help, really appreciate the offer. Looking > forward to working closely with you. > > > > > -----Original Message----- > > From: Travis Graham [mailto:tgra...@tgraham.us] > > Sent: Friday, October 11, 2013 5:34 PM > > To: dev@cloudstack.apache.org > > Subject: Re: [ACS43] [DISCUSS] Release management tasks up for grabs > > > > Animesh, > > > > I'm volunteering to help out with the docs. I've put a hold on fixing > > things until there's a Review Board in place for cloudstack-docs to > > make it easier to submit patches. > > > > Travis > > > > On Oct 11, 2013, at 7:01 PM, Animesh Chaturvedi > > <animesh.chaturv...@citrix.com> wrote: > > > > > Folks > > > > > > As per the thread [1] release management for CloudStack is complex > > > and > > runs into many tasks and it is hard for one person to do it all. > > > > > > While I am taking the overall release management for 4.3 release > > > there > > are several areas where we need volunteers: > > > > > > > > > I have put down my thoughts please review and refine as appropriate. > > > > > > # Review board management# > > > > > > - Context: We are lagging severely behind on the reviews of the > > > patches submitted and have around 100 pending reviews > > > - Task Duties: > > > * Periodically check on review board [2] for pending reviews > > > * If reviewers are not called out for the patch direct the > > > submitter > > to our component maintainers page [3] and help identify the > > appropriate reviewer > > > * Follow up with submitter if they have not responded to review > > comments in 5 days > > > * Follow up with reviewers if they have not attended to reviews > > where they are called out > > > * Reminders can be sent out by either replying to review emails or > > adding comments in review board for the patches > > > * Check if a reviewer is overloaded with many pending reviews and > > call out in mailing list that another reviewer to help out is needed > > > * Remind the submitter if the BugId, targeted branch is missing > > > * Remind the submitter to close out the review when the patch has > > been accepted and submitted in the appropriate branch > > > * Close out the review if it submitter for some reason is not able > > to close it out (Administrator privilege is needed) > > > * More details are mentioned in Review board guidelines [4] > > > - We probably need two volunteers one for code contribution and one > > > for test patches contribution > > > > > > > > > # Documentation management# > > > > > > During ACS 4.2 several folks raised questions on insufficient or > > > incorrect documentation, this is an area where we need multiple > > > volunteers to come forward and help fix documentation > > > > > > > > > # Jira issues management # > > > > > > As per thread [5] as community now we have agreed to assign issues. > > There are few things that need to be done to keep the number of > > unassigned issues to a manageable number: > > > > > > 1. Refine our component list > > > 2. Make the primary maintainers the owners of the components in > > > JIRA, > > so that new issues for the components go to the primary maintainers > > first instead of being unassigned. > > > 3. Check with INFRA if a workflow can be setup where if an assigned > > > issue is not change to InProgres in a week it goes back to > > > un-assigned or to primary maintainer of the component (whichever the > > > community > > > prefers) > > > > > > Workflow: > > > 1. The primary maintainers can redistribute the issues to other > > > community members 2. If the assignee can fix the issue promptly they > > > should change the status to "In Progress" indicating that issue is > > being worked on 3. If for whatever reason the assignee is not able to > > fix the issue they should either un-assign or ask someone else to pick > > up the issue. > > > > > > Bug triage: > > > The more hands we can get for bug triage the better it would be so > > > if > > you want to help out please step up. > > > > > > > > > > > > # Release announcement preparation # > > > > > > When we are ready to release there are several activities that need > > > to > > be done and we need help. > > > * Preparing release statement > > > * Preparing press plan > > > * Building docs > > > * Publishing docs to the site > > > > > > > > > > > > I am sure I may have omitted few important activities feel free to > > > add them to the list > > > > > > > > > [1] http://markmail.org/thread/gkrq2inc2bkupner > > > [2] https://reviews.apache.org/dashboard/ > > > [3] > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintai > > ne > > rs+Per+Component > > > [4] > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Gu > > id > > elines > > > [5] http://markmail.org/thread/vtwod332xqwdmll7 > > > > > > > > > Thanks > > > Animesh > > > Committer Apache CloudStack > > > anim...@apache.org > > >
