I'd say we should encourage "experimental" projects to *either* move to SandBox or to GitHub. If we are ready to move to GitHub more immediately, then we could encourage more of them moving to GitHub. However, I don't want the GitHub discussion to sidetrack discussion of cleaning up SVN Modules area (the latter of which likely would be good to clean up *before* 1.8.0).
More inline... On 7/11/2011 8:25 AM, Mark Diggory wrote: > I would say your welcome to start. I think we are talking about projects > not ready or wanting to transition to github yet. > > Mark > > On Mon, Jul 11, 2011 at 9:21 AM, Graham Triggs <grahamtri...@gmail.com > <mailto:grahamtri...@gmail.com>> wrote: > > Would it just be confusing the issue to start talking about GitHub, > or is it actually a good time to bring it into the discussion? > > I'm not advocating for a move of trunk / supported modules to GitHub > (at least, not yet), but if we are moving experimental / development > modules out of their current home, maybe we should consider if > GitHub is a better place for them (where it is theoretically easier > for more people to contribute). > > G > > On 11 July 2011 14:03, Mark Diggory <mdigg...@atmire.com > <mailto:mdigg...@atmire.com>> wrote: > > Hello, > > A couple weeks ago we discussed organizing the modules directory > into > "supported" and "experimental" directories. I'm now of the opinion > that we should just keep "supported" modules under svn/modules and > move the alpha/beta work over into the sandbox area. This will > result > in the supported modules not having to change and the experimental > stuff moving. Seems more logical. The next big question to > answer will > be what is supported and what is experimental. Also, don't we have some basic "groupings" of modules on this wiki page: https://wiki.duraspace.org/display/DSPACE/Modules Based on this, we may want to *move* the "Other Module Projects" to Sandbox (or elsewhere). I also wonder if we should either move or rename many of the "DSpace 2.0 Module Projects". Currently, they are rather confusingly placed, and some share names with DSpace 1.x modules (e.g. http://scm.dspace.org/svn/repo/modules/xmlui). We could also just move things based on project activity (in FishEye). Some of these projects have not seen updates in years or have never seen an update since May 2009, when we migrated to our new SVN. These projects include (Note: Some of this may still be worth keeping in SVN Modules. But, many of the ones last modified in 2009 may now be unsupported/unmaintained.) * dspace-database - last updated June 2010 * dspace-history - last updated May 2009 * dspace-imscp - last updated May 2010 * dspace-ldap - last updated May 2009 * dspace-policy - last updated May 2009 * dspace-radius - last updated May 2009 * dspace-rdf - last updated May 2009 * dspace-sesame - last updated May 2009 * dspace-sip - last updated June 2009 * dspace-srw - last updated June 2009 * dspace-stats - last updated Oct 2009 * dspace-xmlui-rdf-aspect - last updated May 2009 * guice - last updated July 2009 * mapping-db - last updated July 2009 * userdb - last updated July 2009 * xmlui - last updated July 2009 One final note: it could also be worthwhile to "group" common modules together. We have a bunch of "storage-*" modules, which we may want to group together under a common "modules/storage-plugins" module in SVN, or similar. If everyone feels it could be worthwhile, we could also add this topic to this week's Developers Meeting agenda. - Tim ------------------------------------------------------------------------------ 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
