Hi all, To avoid paralysis on this issue could we agree to move those modules that are clearly redundant or experimental into the sandbox ? We could continue discussing what to do with the others in the meantime ?
Cheers, Robin. On Mon, 2011-07-11 at 17:59 +0100, Tim Donohue wrote: > Mark, > > I think that's worth considering, but then we do run into an issue > around what does "supported" mean? > > In my mind, "supported" would mean that it is centrally supported by the > Committers Group. (I.e. it's something akin to the XMLUI, JSPUI, etc. > which are supported/updated/managed by many of us as a team). > > In my mind, this would mean that modules like the 'dspace-imscp' module > (built by MIT/@mire) would not appear in the "supported" category (as it > hasn't been voted on or vetted by the Committers Group as a whole). But, > at the same time, this module seems to not be "experimental", so it also > doesn't fit in the "sandbox" definition. > > So, that's why I had thought we may need a "thirdparty" category, > bringing us to a total of three categories of modules: > (1) sandbox/experimental > (2) centrally supported modules > (3) thirdparty modules > > - Tim > > On 7/11/2011 11:30 AM, Mark Diggory wrote: > > 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. > >>> > >>> > >> > > > > > > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
