> -----Original Message-----
> From: Stuart Lewis [mailto:email@example.com
> Sent: 27 July 2010 10:44
> To: dspace-devel; DSpace GSoC Students
> Subject: Re: [Dspace-devel] July 28 - Special Topic Mtg on
> "GSoC Project Merging & Trunk Mgmt"
> Hi all,
> I'm afraid that I'll not be able to attend the meeting as
> I'll be giving a big demo of our new research management
> system to our faculty at that time.
> >From my perspective as the mentor for Pere's testing
> project, I'd love to see this in trunk a.s.a.p. I've been
> working over the last few days with Pere to look at the 10%
> of tests which are currently failing. Some of these are due
> to subtle errors in the tests, but a lot are also uncovering
> bugs in DSpace. For example I was looking at one bit of code
> last night to see why a test was failing and discovered the
> following bug:
> if (additionalInfo != null)
> int i = 1;
> for (String key : additionalInfo.keySet())
> args[6 + 1] = new FormattableArgument(key,
> Note the type: args[6 + 1], which should be args[6 + i]. So
> the project is already paying dividends in spotting bugs :)
> This is a good win for the GSoC project, and for DSpace in
> general. Pere now has standalone junit tests, and integration
> tests that populate an in-memory database for testing purposes.
> Therefore if we can get the code into trunk, then we can get
> more eyes looking at the test failures and fixing them. We
> can then also work on getting better coverage of tests.
> It would be great if a few people could checkout his branch
> and comment on the tests and the way they make use of things
> like the in-memory database. While they seem to work fine and
> do the job, I'd be interested in hearing from anyone who has
> experience or expertise in this area to make sure we are
> going about this in the right way.
> In terms of getting it committed, I'd be happy for the GSoC
> students to perform the commit or merge - save us (the
> mentors) from doing it and causing a bottleneck, and what is
> the worst that can happen? It all gets deleted or messed up,
> in which can we revert to an old revision and no harm is done.
> Stuart Lewis
> IT Innovations Analyst and Developer
> Te Tumu Herenga The University of Auckland Library Auckland
> Mail Centre, Private Bag 92019, Auckland 1142, New Zealand
> Ph: +64 (0)9 373 7599 x81928
> On 23/07/2010, at 8:40 AM, Tim Donohue wrote:
> > All,
> > This an early notification of next week's Special Topics Developer
> > Meeting on the subject of "GSoC project merging, Trunk
> Management, and
> > Commit Rights".
> > This meeting will take place on Weds, July 28 in the #duraspace IRC
> > channel at 20:00 UTC. To determine your local time, check the world
> > clock:
> > =0&p1=0
> > == Additional Background Info ==
> > In yesterday's DSpace Developer Meeting, there was a lot of
> > around how best to manage merging of "ready" Google Summer of Code
> > (GSoC) projects into DSpace 1.7 code on Trunk. Several different
> > scenarios/options were discussed, which made us realize we
> really need
> > to bring this to a broader discussion. We've attempted to
> > this discussion on the below wiki page (feel free to add your own
> > comments/suggestions on the wiki or via email to this list):
> > tion+Cycles
> > Essentially, a few key issues came up:
> > (1) How liberal or conservative do we want to be with allowing GSoC
> > students to commit/merge "ready" code in preparation for DSpace 1.7?
> > This includes:
> > (1a) How liberal/conservative do we want to be about giving
> > temporary commit rights to Trunk? Or, would we rather they
> merge their
> > code together elsewhere (e.g. a common branch based on Trunk)?
> > (1b) How liberal/conservative do we want to be about allowing for
> > temporary "breakage" of trunk (which could happen as
> several projects
> > attempt to merge code)?
> > (2) How much extra reviewing do we want of GSoC projects
> whose Mentors
> > feel the code is "ready" for broader distribution/release
> in DSpace 1.7?
> > If extra reviewing is warranted, how do we want to ensure
> this review
> > is done in a timely manner (i.e. in time for DSpace 1.7, as
> > We've thought it best to set aside next week's Developers
> Meeting for
> > deeper discussion of these questions.
> > As GSoC is wrapping up soon, this meeting really should
> concentrate on
> > decisions around *GSoC* specifically. We obviously can discuss
> > committer rights in general as well as general trunk
> management. But,
> > the primary goal is to answer these questions pertaining to GSoC
> > project merging. If necessary, we can always schedule a separate
> > meeting to concentrate discussion on general Committer Rights and
> > Modularization/Trunk management.
> > ----
> > Questions or comments? Let me know or send them to this listserv.
> > - Tim
> > -------- This SF.net email is sponsored by Sprint What will you do
> > first with EVO, the first 4G phone?
> > Visit sprint.com/first
> > _______________________________________________
> > Dspace-commit mailing list
> > Dspacefirstname.lastname@example.org
> > https://lists.sourceforge.net/lists/listinfo/dspace-commit
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for
> a share of $1 Million in cash or HP Products. Visit us here
> for more details: