All, I wonder then if everything marked as "unstable, unreleased" should be moved to something like:
http://scm.dspace.org/svn/repo/sandbox/modules/ OR, if we wanted to keep all the "Modules" in one SVN area, we could flip the path around into something like: http://scm.dspace.org/svn/repo/modules/sandbox/ This would give us a specific SandBox area which is only for Maven Modules (similar to how there is a specific Sandbox area for GSoC at /sandbox/gsoc/). I, personally, would also be tempted to move the MIT/@mire specific projects to another location (or rename them somehow). I see those as "third-party" modules, which haven't been formally accepted/adopted by the Committers Group (even though a few committers may have worked on them, we've never voted to adopt them, as far as I'm aware). So, those could be moved to something like: http://scm.dspace.org/svn/repo/modules/thirdparty/ Or if people don't like the term "thirdparty", they could be /modules/incubator/ or /modules/extensions/ or something else that implies they are not centrally supported by the Committers, but that they still may be stable or supported by another entity. Modules which are then "officially supported" by the Committers could just remain in: http://scm.dspace.org/svn/repo/modules/ (Or if we really wanted to, we could create a sub-directory called /modules/supported/ or /modules/official/) In this way, the Modules workflow could look something like this: (1) New modules always start in "Sandbox" area (2) Once they are stable and/or released, they can ask to move to "ThirdParty"/"Incubator" area, OR (3) They can also ask to be fully endorsed/supported by the Committers Group. If they are, they would move to the "Official"/"Supported" area. Otherwise, they could remain in the "ThirdParty" area for as long as they wanted to, and continue to perform all their releases from that location. (SIDENOTE: Obviously, if we then eventually move to GitHub, then the "SandBox" area is not as necessary anymore. But, we still may want to bring forward the idea of the "Official"/"Supported" area, to highlight those modules which are officially supported by the Committers Group.) - Tim On 7/11/2011 10:52 AM, Mark Diggory wrote: > On Mon, Jul 11, 2011 at 11:39 AM, Tim Donohue<[email protected]> wrote: >> * dspace-database - last updated June 2010 > > Stable, adds dspace DataSource into Spring applicationContext, unreleased. > >> * dspace-history - last updated May 2009 > > Work Done by MIT on audit trail recorded in Sesame Triplestore. It is > unstable, unreleased. > >> * dspace-imscp - last updated May 2010 > > Work done by MIT/@mire on IMSCP packager. It is stable and I believe > it is released. > >> * dspace-ldap - last updated May 2009 > > Example of an Authenticator Addon, unstable, unreleased. > >> * dspace-policy - last updated May 2009 > > Work Done by MIT on a policy store in Sesame Triplestore. It is > unstable, unreleased. > >> * dspace-radius - last updated May 2009 > > Work Done to show how to create a Radius Authenticator Addon, stable, > unreleased. > >> * dspace-rdf - last updated May 2009 > > Sesame RDF support used in LoD XMLUI rendering Addon. > >> * dspace-sesame - last updated May 2009 > > Supports Work Done by MIT on a policy and history store in Sesame > Triplestore. It is unstable, unreleased. > >> * dspace-sip - last updated June 2009 > > Unsure > >> * dspace-srw - last updated June 2009 > > Attempt to get SRW managed under dspace umbrella, stable, partially released. > >> * dspace-stats - last updated Oct 2009 > > Is replicated in trunk, shouldn't be in trunk, should be maintained > here instead. > >> * dspace-xmlui-rdf-aspect - last updated May 2009 > > LoD RDF rendering addon for XMLUI, stable, but based on DSpace 1.5 > >> * guice - last updated July 2009 >> * mapping-db - last updated July 2009 >> * userdb - last updated July 2009 >> * xmlui - last updated July 2009 > > All Old DSpace Work to get Services in DSpace 2.0 separated apart for > inclusion into 1.x most can either go back into 2.x or into sandbox. > > ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
