Versions Compared

Old Version 13

changes.mady.by.user Tim Donohue

Saved on

compared with

New Version 14

changes.mady.by.user Tim Donohue

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  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 merging 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 have a Committer (GSoC mentor?) 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.

Key Questions:

  1. How liberal or conservative do we want to be with allowing GSoC students to commit/merge "ready" code directly to Trunk? This includes:
    1. How liberal/conservative do we want to be about giving students temporary commit rights to Trunk?
    1. How liberal/conservative do we want to be about allowing temporary "breakage" of trunk (which could happen as several projects attempt to merge code)?
  1. How much "red tape" or extra reviewing do we want of GSoC projects whose Mentors feel the code is "ready" for broader distribution/release in DSpace 1.7?

Issues In Relation to Asynchronous Release and Modularity

...