Developers Meeting on Weds, July 21, 2010

Agenda

• Any Announcements / Additional Agenda Items?
• GSoC updates
• Review of discussions out of OR10 – any comments / questions / thoughts:
  • DevMtg 2010-07-05 - OR10 Meeting – developer meeting notes from OR10
  • RE: Learning more about Fedora – there are options available to all of us, which you can choose to look at if they interest you.
    • Do we want an "Intro to Fedora" webinar? Thorny Staples (DuraSpace) has offered to do one & record it if any/all are interested.
    • Fedora "Getting Started" guides
    • Fedora Developer Weekly Meetings: https://wiki.duraspace.org/display/FCREPO/Developer+Meetings
• Topic for next "Special Topics" Meeting? Several 'ToDo' topics came out of OR10 discussions:
  • TODO: Full meeting on Discussion of Commit Rights & Committer Governance models. Should we still be called "committers", or give out commit rights more liberally?
  • TODO: Dependencies between Trunk and Modules are a bit "muddy". Full meeting on discussion of how we should split these "service boundaries" – so how do we want to manage trunk & modules?
  • TODO: Where do we all stand on asynchronous module releases? (Mark Diggory)
• JIRA Catch-Up – starting with issue DS-533 (and getting as far as we can).
  • Search for recent JIRA Issues

Meeting Notes

GSoC – how to get projects in Trunk, Future Special Topic Mtg on GSoC & Commit Rights, Future "Intro to Fedora" Training

• Majority meeting discussed how to get GSoC projects which are "ready" adopted into Trunk
• Several scenarios/options presented (one or more should be adopted):
  • Require students to create JIRA issues for their projects? (Preferable to have several tickets for a single project, breaking it into components in varying states of readiness)
  • Allow "ready" projects (or parts of projects) to be committed immediately to Trunk (by the students themselves) – especially for the REST project
  • Allow "ready" projects (or parts of projects) to be committed immediately to a Branch (where they will be merged by the students themselves). After a quick review process, this branch would be merged back into Trunk for DSpace 1.7 release.
  • Keep the GSoC projects where they are for review, and merge into trunk later
    • Downside is that this is the "old way of handling GSoC projects", which hasn't worked out well in the past. To date, no GSoC project has ever been accepted into Trunk code.
• Discussion of no longer treating Trunk as "sacred" – perhaps we allow students to merge code here and potentially temporarily "break things"? However, this goes against our current Guidelines for Committing
• Proposal for an Special Topic Meeting next week to decide following: (See Managing Release and Integration Cycles page for more details on this Special Topic Meeting)
  1. Propose that "ready" GSoC Projects be committed to Trunk (or alternatively to a common Branch for quick review and then moved to Trunk)
  2. Because of this, we may need to review our Guidelines for Committing – should Trunk be treated "sacred"?
  3. Also may need to begin discussion of "Commit Rights" – do we give temporary full commit rights to GSoC students, or do we only allow their mentors to commit the code?
• Future Special Topics Meeting:
  • Meeting to discuss Trunk & Module dependencies along with asynchronous module releases
• Brief discussion of Fedora Training
  • All in agreement that an "Intro to Fedora" webinar (with a recording) would be nice. Tim will investigate with DuraSpace.

Meeting Transcript

• Full IRC Transcript at - http://www.duraspace.org/irclogs/index.php?date=2010-07-21