Page History

...

This proposal originally arose out of the Google Summer of Code project with the need to actually have GSoC students help with the code merge of their projects into Trunk. But, as students are not "Committers", they currently are limited in receiving rights to Trunk (under our current policies). It is recommended that we hold a Special Topic meeting next week (July 28, 2010), and try and determine what to do in this scenario. Obviously, this proposal then leads to other questions of how we may view committer rights.

Discussion of how best to begin preparing/merging "ready" GSoC code in preparation for DSpace 1.7 began in the Developer Meeting on July 21, 2010.

Four options were discussed – there may be more options that we haven't thought of:

1. 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)

   • Wiki Markup
     We'd probably want to encourage this, no matter which option we choose below \[Tim Donohue\]

2. Allow "ready" projects (or parts of projects) to be merged & committed immediately to Trunk (by the students themselves)
3. Allow "ready" projects (or parts of projects) to be merged & committed immediately to a Branch (by the students themselves). After a quick review process, this Branch would be merged back into Trunk for DSpace 1.7 release.
4. Keep the GSoC projects where they are (in SVN). Schedule them for review, and merge into Trunk later on.
   • This option is how we've done things in the past. It is worth noting that, to date, no GSoC project code has ever been accepted into Trunk, as oftentimes they are "abandoned" or left in an uncertain state after the students complete their work.

Issues In Relation to Asynchronous Release and Modularity

...