+1
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Asking whether markets are efficient is like asking whether people are smart.
pgpdp9WaTGjLj.pgp
Description: PGP signature
--
AppSumo Presents a FREE Video fo
+1
On 15 July 2011 04:49, Tim Donohue wrote:
> +1 - sounds good.
>
> On 7/14/2011 3:24 AM, Robin Taylor wrote:
> > 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 discuss
+1 - sounds good.
On 7/14/2011 3:24 AM, Robin Taylor wrote:
> 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, Ro
Yes
On Thu, Jul 14, 2011 at 1:24 AM, Robin Taylor wrote:
> 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, Robi
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,
>
>
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
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
s
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/mo
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
On Mon, Jul 11, 2011 at 11:39 AM, Tim Donohue 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
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 wrote:
> Would it just be confusing the issue to start talking about GitHub, or is
> it actually a good time to bring it
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
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 supporte
13 matches
Mail list logo
