Just my tuppence worth... If there is a problem then I don't think it will be with allowing the students to commit their code. I doubt they are any more likely to make a mess of it than I would be and any big mistake is easily spotted and easily corrected as you say. The problem would be code being committed with significant bugs in it that aren't spotted until later, at which point the student has returned to their studies. We integrated the code from a GSOC project into a local project last year and whilst it was an impressive body of work for which the student deserves credit it still needed at least a couple of weeks work to be fit for purpose. Finding the time in that case was not a problem as it was part of a bigger project. We need to be aware that a large group of commits such as this will introduce a significant amount of bugs. At best this will mean greater demands on all Dspace developers in the run up to the next release, at worst it will mean a more buggy release. On balance I'm in favour of asking the students to do the commits but we may want to impose a development freeze in the run up to 1.7 earlier than has previously been the case and dedicate more time to testing and bug fixes.
Cheers. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 > -----Original Message----- > From: Stuart Lewis [mailto:[email protected]] > 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, > 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+Integra > > 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 > 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 > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ 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
