my recommendation is to just have one level. svn/repo/modules <-- supported
svn/repo/sandbox <-- experimental. this is the simplest approach. tools like IDEA map these svn directories to local directory names, I want to see this stay as flat as possible. If you want more classifications, use svn/repo/[classifier] Mark On Mon, Jul 11, 2011 at 12:25 PM, Tim Donohue <tdono...@duraspace.org> wrote: > 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<tdono...@duraspace.org> >> 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. >> >> > -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Esperantolaan 4 - Heverlee 3001 - Belgium ------------------------------------------------------------------------------ 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 Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
