Special Topic Meeting on Weds, July 28, 2010

Agenda

Special Topic Meeting to discuss "GSoC project merging, Trunk Management, and Commit Rights"

In the July 21 DSpace Developer Meeting, there was a lot of discussion around how best to manage merging of "ready" Google Summer of Code (GSoC) projects into DSpace 1.7 code on Trunk. Several different scenarios/options were discussed, which made us realize we really need to bring this to a broader discussion. We've attempted to summarize this discussion on the Managing Release and Integration Cycles wiki page (feel free to add your own comments/suggestions).

Essentially, a few key issues came up:

1. How liberal or conservative do we want to be with allowing GSoC students to commit/merge "ready" code in preparation for DSpace 1.7? This includes:
   1. How liberal/conservative do we want to be about giving students temporary commit rights to Trunk? Or, would we rather they merge their code together elsewhere (e.g. a common branch based on Trunk)?
   2. How liberal/conservative do we want to be about allowing for temporary "breakage" of trunk (which could happen as several projects attempt to merge code)?
2. How much extra reviewing do we want of GSoC projects whose Mentors feel the code is "ready" for broader distribution/release in DSpace 1.7? If extra reviewing is warranted, how do we want to ensure this review is done in a timely manner (i.e. in time for DSpace 1.7, as necessary)?

As GSoC is wrapping up soon, this meeting really should concentrate on decisions around GSoC specifically. We obviously can discuss committer rights in general as well as general trunk management. But, the primary goal is to answer these questions pertaining to GSoC project merging. If necessary, we can always schedule a separate meeting to concentrate discussion on general Committer Rights and Modularization/Trunk management.

ListServ Discussions

• See recent 'dspace-devel' thread: http://www.mail-archive.com/dspace-devel@lists.sourceforge.net/msg03826.html

Meeting Notes

GSoC – discussion of what may be "trunk ready" and how to get code into "trunk"

• Discussion of which DSpace Summer of Code2 projects are "trunk ready" (i.e. ready for DSpace 1.7 release). Two projects proposed to add to Trunk:
  • GSOC10 - Add Unit Testing to Dspace
    • Seem to have general agreement that this code should be accepted to Trunk. Although not all unit tests are completed, the framework is necessary to get into Trunk so that we can continue to build out additional unit tests, etc.
  • GSOC10 - DSpace REST API
    • Some disagreement on accepting this project immediately. Most seem in favor, but a few concerns posted.
      • grahamtriggs: "I've only briefly scanned the commits, but the code where it is getting stack traces and using it to determine if there is a loop seems rather scary, and is pointing to a flawed designed"
• How should this code be committed?
  • General agreement that Mentors should "sponsor" a student's access to Trunk. Students would essentially be given temporary commit rights to Trunk in order to merge their code in (as necessary).
    • mhwood: Could the mentor "sponsor" (or not) his student's access to trunk? "Sponsor" meaning, "I think the code is good, I think the student knows his way around the SCM, and I'll help clean up if I was mistaken."
• Voting:
  • Proposal: "All those in favor of having Pere Villega commit his "ready" Unit Testing code (with sponsorship from Stuart Lewis) to Trunk before the end of GSoC?"
    • +1 votes : 7 people
    • -1 votes : 0 people
    • 0 votes : 0 people
    • Final Results: Proposal passes – the Unit Testing code should be added to Trunk before end of GSoC.
  • No other proposals were made (ran out of time for discussion). During next week's meeting (Aug 4), we will continue discussion of whether REST project should also be added to Trunk.

Meeting Transcript

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