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, additionalInfo
.get(key));
i++;
}
}
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.
Thanks,
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:
> http://www.timeanddate.com/worldclock/fixedtime.html?hour=20&min=0&sec=0&p1=0
>
>
> == Additional Background Info ==
>
> In yesterday's DSpace Developer Meeting, there was a lot of discussion
> 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 summarize
> this discussion on the below wiki page (feel free to add your own
> comments/suggestions on the wiki or via email to this list):
>
> https://wiki.duraspace.org/display/DSPACE/Managing+Release+and+Integration+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 students
> 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 necessary)?
>
> 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 -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Dspace-commit mailing list
> [email protected]
> 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:
http://ad.doubleclick.net/clk;226879339;13503038;l?
http://clk.atdmt.com/CRS/go/247765532/direct/01/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
