[sakai-pmc] Summary of today's Sakai Release team meeting

[Neal Caidin]

Hi Max,

One of the experienced branch managers gave me this information:

Branch Manager (minimal requirements)
- Use jira (and occasionally email/skype) to verify which issues are 
necessary and appropriate to merge to the Maintenance Branch.
- Merge the issue. (If the merge isn't clean, contact the CLE Team for 
assistance.)
- Set the Maintenance Branch's status field to "Resolved" and set the 
Fix Version to the appropriate maintenance branch version.

Requires knowledge of jira, subversion. Ideally can perform minor 
conflict resolution. Also ideally can attend the Thursday release call.

Average probably about 4 hours a week. (About 5 minutes per issue)


-- I am guessing we could also provide mentorship for this role, though 
would want to confirm that before making any commitment :-) .
If you need more technical details or requirements we could probably 
drill down a little. For example, merging issues implicitly means that a 
strong command of Subversion (svn) and access to our subversion 
repository is required. Not everyone is granted access to the subversion 
repository but if you could have a good candidate, we would look into 
it, of course. :-)

Thanks!
Neal

> Max Whitney <mailto:max at nyu.edu>
> February 7, 2014 at 3:24 PM
> Hello Neal:
>
> Can you identify the duties of a branch manager, as well as an 
> estimate of the amount of time required, over what duration? This will 
> help us assess whether we can contribute someone.
>
> Thanks,
> Max
>
>
> Neal Caidin <mailto:neal.caidin at apereo.org>
> February 6, 2014 at 5:08 PM
> [ to sakai-pmc and Sakai release team]
>
> Summary of today's release call [1] :
> ------------------------------------------------------------
> * We would like to proceed with branching Sakai 10 as soon as 
> possible. The main to-dos before branching are to make Elastic Search 
> the default search tool and the to-do's outlined by Anthony in his 
> email, which are :
>
> TODO for contrib tools Signup Tool, Delegated Access, and Roster2 ... 
> plus dependencies [copy/pasted from Anth's email]
> 1.  Migrate projects from contrib to core (svnadmin dump, retain history)
> 2.  Update <scm> paths once projects are in core  - Anthony
> 3.  Fold Jira contrib projects into SAK - Anthony
>
> * Matt Jones is investigating TODO #1  .
>
> * AsahiNet is working on the Elastic Search default issue [2].
>
> * Neal will send out a lazy consensus proposal outlining the plan to 
> proceed with Sakai 10 branching to the sakai-dev list .
>
> * We reviewed the rest of the blockers, the ones we did not review on 
> the meeting last week. The team noted that we have a bit of a 
> categorization problem in Jira. In an ideal scenario, anything 
> assigned a priority of blocker, would be a true blocker for the 
> release. But that is not the case. Today we used a combination of 
> demoting some items to critical, using labels on some blockers to make 
> it clear that they should not hold up Sakai 10, and leaving some as 
> blockers for now, recognizing that while we would like them to get 
> done for Sakai 10, they might not truly block the release. A fraction 
> of the issues seem to be true blockers, for which we would not release 
> Sakai 10.  Note: We should be thinking of ways of cleaning up how we 
> manage blocker/criticals in a more consistent way (maybe a topic for a 
> Community Coordinator/PMC discussion?).
>
> * We still need to identify Sakai 10 branch managers. Any volunteers?  
> Once we have Sakai 10 branch managers, Sakai 2.9.x seems likely only 
> to receive critical patches unless some folks from the community stand 
> up and volunteer. We would need a critical mass of qa testers and 
> branch managers for merging and bug fixers to have a 2.9.x community 
> supported release beyond 2.9.3 . At the moment, I'm not aware of such 
> critical mass for 2.9.x .
>
> * Edia Skin manager did not make it into Sakai 10, but there is 
> potential it could make it into a Sakai 10.x or Sakai 11.
>
> * Kind of a minor note: I mentioned on the call that I think we need a 
> change process so that if after branching some feature emerges as a 
> candidate for Sakai 10.0, now that the scope is frozen, there is a way 
> someone could propose the feature be added and the Sakai Release team 
> and/or PMC could evaluate the risk/benefits and any potential impact 
> to the schedule to make a determination. By default, there would be no 
> new items, but we know from experience that this does happen 
> sometimes, so it would be good to be prepared. 2 cents.
>
> [1] Release team notes - http://etherpad.ctools.org/rmmt-2014-02-06
>
> [2] https://jira.sakaiproject.org/browse/SRCH-130
>
> Thanks,
> Neal
>

-- 
Neal Caidin
Sakai Community Coordinator
Apereo Foundation
neal.caidin at apereo.org
Skype me! (but let me know in advance for the first interaction) - nealkdin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140207/c64eaf80/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-pmc/attachments/20140207/c64eaf80/attachment.jpg