Below is the transcript of a committer's meeting held on #duraspace at irc.freenode.net at 20:00 GMT on September 16, 2009.
We intend to hold the next meeting on #duraspace Wednesday, September 23 at 16:00 GMT. (*) The #duraspace channel is logged, you can see past meetings (including Fedora Commons meetings as well) at http://www.duraspace.org/irclogs/ You can see the upcoming (weekly) schedule as well as other DSpace developer events on the DuraSpace public calendar at: http://www.google.com/calendar/hosted/fedora-commons.org/embed?src=fedora-commons.org_o5iransoopr4i05f7ajpkab7ms%40group.calendar.google.com Anyone is welcome to attend. (*) This is one of the weeks when the meeting is at 4am NZ time (Stuart, Kim), and Tim Donohue and I are both scheduled elsewhere, so we'll need someone to moderate the discussion, please. Meeting Summary: The first 15 minutes were allocated to Jira Review. We reviewed half of the new issues from the last three weeks before we ran out of time. Metadata exposure on embargoed items was discussed, and we acknowledged that perhaps a central mechanism for visibility control is in order. We reconfirmed the goal of assembling 1.6 before DSUG. Transcript of committer's mtg (pieced together, logbot was offline): [ 4:00pm ] bradmc : Hi Folks, we'll start a committer's meeting at about 20:05 GMT. [ 4:00pm ] bradmc : In the interim, please think about topics and toss them out. [ 4:00pm ] bradmc : At the start of the meeting, we're going to spend up to 15 minutes doing a jira review. [ 4:01pm ] bradmc : There are twelve issues since the most recent issue we've reviewed. [ 4:01pm ] jat_ysu joined the chat room. [ 4:02pm ] bradmc : The Jira issues for review can be found at http://wiki.dspace.org/index.php/JIRA_Cleanup#Issues_Covered and you may find the jira search link there to be the most convenient way to view them. [ 4:02pm ] bradmc : I could use a volunteer to either throw the issues, or time ad summarize the discussion; choose a role. [ 4:02pm ] bradmc : ad = and [ 4:02pm ] mhwood : wiki is still flaky but I got in eventually. [ 4:04pm ] • kshepherd can paste the issue ids + descriptions [ 4:04pm ] bradmc : Great, please start from the end and work forward (DS-293, 293, 294, ...) [ 4:04pm ] bradmc : I'll do the timing and summary of votes, then. [ 4:04pm ] stuartlewis : Morning all [ 4:05pm ] bradmc : Hi Stuart. Looks like you get to just vote today [ 4:05pm ] bradmc : People ready to start the Jira review? [ 4:05pm ] kshepherd : ok [ 4:05pm ] kshepherd : [DS-292] - "Clone" collection [ 4:06pm ] bradmc : DS-292: 0 (as per usual on our first of the day). extra minute: [ 4:07pm ] stuartlewis : Would be nice, if there was a volunteer. Not 100% trivial as we might not want tomcat rewriting the input-forms.xml [ 4:07pm ] mhwood : -1 nice idea but no patch [ 4:07pm ] rrodgers joined the chat room. [ 4:07pm ] bradmc : Voting on DS-292 [ 4:07pm ] kshepherd : -1, agreed nice idea but no patch, getting too close [ 4:07pm ] bollini joined the chat room. [ 4:08pm ] jat_ysu : -1 [ 4:08pm ] bradmc : DS-292: -3, no patch, mark as won't fix [ 4:08pm ] jat_ysu : Can it be placed for perhaps a later release fix or enhancement? [ 4:08pm ] bradmc : Yes. Shall we take a minute to discuss what to do with these? [ 4:09pm ] kshepherd : yeah, my understanding is that this voting is for 1.6, right? [ 4:09pm ] stuartlewis : Can we add a category along the lines of 'closed, but willing to reopen' [ 4:09pm ] jat_ysu : This one is particularly useful, and while we are winding down for 1.6, it just doesn't leave much time to work onit. [ 4:09pm ] bradmc : Leave it open for post 1.6, add a note that says needs someone to develop a patch? [ 4:09pm ] kshepherd : that could be a good idea [ 4:09pm ] jat_ysu : yes.. [ 4:09pm ] kshepherd : ok, next one [ 4:09pm ] mhwood : Agreed. [ 4:09pm ] bradmc : Let's start by adding a note; in future we'll work out if we need a category. [ 4:09pm ] kshepherd : [DS-293] - Choose/change collection form from web UI - http://jira.dspace.org/jira/browse/DS-293 [ 4:10pm ] stuartlewis : This might depend on the GSOC project [ 4:10pm ] stuartlewis : We need an update from Mark to find out if it could go in 1.6 [ 4:11pm ] bradmc : DS-293: 0, leave as is for later review when more is known. [ 4:11pm ] kshepherd : [DS-294] - There is no way to set EPerson's preferred language - http://jira.dspace.org/jira/browse/DS-294 [ 4:11pm ] mdiggory : hi... sorry... swamped. [ 4:11pm ] bollini : hi all.. I have missed the meeting start, BTW the channel logging is stopped at 14th Sept [ 4:12pm ] stuartlewis : +1 [ 4:12pm ] mhwood : +1 [ 4:12pm ] rrodgers : +1 parity [ 4:12pm ] bradmc : DS-294: +3 (volunteer?) [ 4:13pm ] bradmc : DS-294: +3, unassigned, for 1.6. [ 4:13pm ] mdiggory : right... [DS-294] Gaurav would be very interested to see his work get into 1.6 [ 4:13pm ] kshepherd : bradmc: i was intending to volunteer for the small xmlui jobs, that looks like one, so perhaps we should assign to me [ 4:13pm ] rrodgers : how mature is it? [ 4:14pm ] bradmc : DS-294: +3, assign to ksheperd for 1.6. [ 4:14pm ] mdiggory : he lurked last week in hopes that he would get to talk about it... but the JIRA activities took most of our time [ 4:14pm ] • bradmc has someone looking at #duraspace channel logging right now. [ 4:14pm ] mdiggory : rrodgers: we need testers/reviewers to verify the work [ 4:14pm ] kshepherd : [DS-295] - CC License being assigned incorrect Mime Type during submission. - http://jira.dspace.org/jira/browse/DS-295 [ 4:15pm ] mhwood : +1 [ 4:15pm ] stuartlewis : +1 [ 4:15pm ] kshepherd : +1 [ 4:15pm ] rrodgers : 0 (based on a bug) [ 4:15pm ] stuartlewis : bradmc: If nothing else, my client logs (I think!) [ 4:15pm ] bradmc : DS-295: +3, unassigned for 1.6 [ 4:15pm ] kshepherd : (assuming the patch is tested) [ 4:15pm ] bradmc : stuartlewis, mine too. [ 4:16pm ] kshepherd : rrodgers: a bug in the patch? [ 4:16pm ] kshepherd : ok, well, next one [ 4:16pm ] kshepherd : [DS-296] - DspaceFeedGenerator not serializable?! - http://jira.dspace.org/jira/browse/DS-296 [ 4:16pm ] rrodgers : no in concept - prior to 1.5 that licence wasn't linked to [ 4:17pm ] kshepherd : ah [ 4:17pm ] rrodgers : but we still may want to fix it as an interim measure [ 4:17pm ] mdiggory : what on earth? [ 4:17pm ] mdiggory : yes. [ 4:17pm ] bradmc : DS-296: 0, extra minute: [ 4:17pm ] stuartlewis : kshepherd: You suffered from this too didn't you? Did you work out what as going on? (ds-296) [ 4:18pm ] kshepherd : 0, i've encountered the problem but have no idea how to fix [ 4:18pm ] mdiggory : cocoon/ehcache searialization [ 4:18pm ] mhwood : 0 [ 4:18pm ] kshepherd : and i wasn't able to tie it to any loss of service specifically [ 4:18pm ] rrodgers : 0 [ 4:19pm ] bradmc : DS-296: 0, add a note: reviewed, unsure of next steps, more data would be nice. [ 4:19pm ] stuartlewis : kshperherd: Did the problem go away? [ 4:19pm ] kshepherd : so far [ 4:19pm ] mdiggory : I'm not sure why one would want to serialize the generators themselves. I'd think ehcache would just want to cache the result [ 4:19pm ] kshepherd : i'll add my own notes [ 4:19pm ] kshepherd : [DS-297] - Refactor SQL source and Ant script to avoid copying Oracle versions over PostgreSQL [ 4:20pm ] mdiggory : Larrys not here today to comment on it [ 4:20pm ] rrodgers : 0 [ 4:20pm ] bradmc : (last issue for today; we're at the end of our time block) [ 4:20pm ] kshepherd : 0 [ 4:20pm ] mhwood : +1 documentation fix [ 4:20pm ] stuartlewis : 0 (would be happy either way) [ 4:20pm ] bradmc : DS-297: +1 treat as a doc fix? Jeffrey? [ 4:20pm ] mdiggory : yes, this is an example of stale docs [ 4:21pm ] jat_ysu : I'm looking at it now. [ 4:21pm ] jat_ysu : yes, it can be updated.... [ 4:21pm ] bradmc : Let's get some topics working for committer's Mtg: [ 4:21pm ] bradmc : DS-297: +1, Doc fix, assign to jtrimble for 1.6 [ 4:21pm ] jat_ysu : k [ 4:22pm ] bradmc : We got through 6 of the 12 issues that opened up in the three week window since we snapshotted for Jira review. That appears to be a sustainable pace at 15 minutes / week. [ 4:22pm ] rrodgers : Yes, this prevents big backlogs [ 4:23pm ] mhwood : Topic: how to activate Solr-based statistics so we can test it [ 4:23pm ] kshepherd : if we get some time at the end, i wouldn't mind someone taking a quick look at DS-304 and commenting on whther it's as important as i think it is, and what steps we might take [ 4:23pm ] bradmc : Go ahead mhwood while other topics are tossed out. [ 4:23pm ] kshepherd : +1 on the solr stuff [ 4:24pm ] mhwood : No, I mean I need to know how. [ 4:24pm ] mdiggory : Hi [ 4:24pm ] mdiggory : sorry forthe delay in response [ 4:24pm ] bradmc : Are you with us, mdiggory, or still tied up with real work? [ 4:25pm ] mdiggory : I'm here now [ 4:25pm ] mdiggory : Solr stuff... UI work is still being fine tuned [ 4:26pm ] mdiggory : I did some refinement of the solr installation last week and have been working on how to outline a testing process still [ 4:26pm ] kshepherd : for those of us that aren't too familiar with solr generally, do you have any recommended reading? don't seem to have been many books written yet [ 4:26pm ] mdiggory : that said, installation does not currently differ from that of dspace... [ 4:27pm ] mdiggory : A rather important book did just hit the market [ 4:27pm ] michaeldb : http://www.amazon.com/exec/obidos/tg/detail/-/1847195881/ref=ord_cart_shr?_encoding=UTF8&m=ATVPDKIKX0DER&v=glance [ 4:27pm ] stuartlewis : mdiggory: Any projected timescales for when it might be ready? [ 4:27pm ] mdiggory : authored by the LucidImagination folks [ 4:27pm ] mdiggory : you gave me two weeks last week [ 4:27pm ] mdiggory : I'm still working to make that timescale [ 4:27pm ] stuartlewis : Excellent [ 4:28pm ] bradmc : Is that two weeks in the "free beer, tomorrow" sense? [ 4:28pm ] bradmc : Other topics for discussion today? [ 4:28pm ] mdiggory : you will more than likely see a ramp up this/next week because after that... we have a freight train of a project coming at us [ 4:29pm ] rrodgers : kshepherd: re 304, is exposed metadata a problem? (Embargo doesn't hide it generally) [ 4:30pm ] kshepherd : rrodgers: the people i'm working with agree re: publisher embargos, but at my institutions at least, thesis embargos require items to be completely undiscoverable [ 4:30pm ] kshepherd : hrm, ignore undiscoverable [ 4:30pm ] bollini : bradmc: http://jira.dspace.org/jira/browse/DS-236 should this be included in 1.6? [ 4:30pm ] kshepherd : taht's a seperate issue. but they do requrie metadata to be hidden as well. [ 4:30pm ] mdiggory : rrodgers: we've never seen a case where the embargo should exclude the item from search and browse [ 4:31pm ] rrodgers : Not a topic - but can someone give me commit right to scm? I have stuff to check in [ 4:31pm ] mdiggory : but I suspect one is out there.... securing access to metadata for embargoed or private items would seem a much larger project [ 4:31pm ] kshepherd : rrodgers: the fact that the UI does show a "Restricted item" message when a user browses to an item they don't have READ access on, but browsing to the METS generator shows them the item just fine, seems to be inconsistent [ 4:31pm ] mdiggory : rrodgers: looking [ 4:32pm ] kshepherd : the JHU embargo does address this, but involves a db schema change [ 4:32pm ] mdiggory : rrodgers: make yourself an account to get svn perms started [ 4:33pm ] mdiggory : https://scm.dspace.org/trac/dspace [ 4:33pm ] kshepherd : i did't think of DS-304 as relating to embargos, really, just an inconsistency in how restricted items are handled, though it is true that we mostly concentrate on restricted bitstreams [ 4:33pm ] rrodgers : mdiggory: ok will do [ 4:33pm ] stuartlewis : rrodgers: Have you got a trac account? Can't seem to see one for you. [ 4:33pm ] mdiggory : stuartlewis: we're on it [ 4:33pm ] stuartlewis : Whoops - sorry for the duplication! [ 4:34pm ] rrodgers : mdiggory: done [ 4:35pm ] mdiggory : kshepherd: I don't know... [ 4:35pm ] mhwood : I still think that the access decision needs to be pulled to a more central place. There was a note on one of the lists recently asking about SRW and access control. This is going to break over and over again as plugins are added. [ 4:35pm ] stuartlewis : It does seem to go against natural expectations, that you can still access the metadata of an item that is fully locked down. [ 4:35pm ] bradmc : bollini: Re DS-236, it appears we've failed to record from our 9-09 meeting this decision: [ 4:35pm ] bradmc : [15:03] <bradmc> DS-236: +3: for 1.6, assign to larry stone. [ 4:35pm ] bradmc : [15:03] <bradmc> (larry reassign to andrea if needed) [ 4:35pm ] rrodgers : kshepherd: I agree that the whole metadata exposure is a big issue - but DSpace was deliberately designed that way, for better or worse [ 4:35pm ] bradmc : mhwood: +1 on that access control thought. [ 4:35pm ] mdiggory : but, we should recommend how to change this exposure and if we want it enabled by default [ 4:35pm ] kshepherd : well, it's the opposite of what will happen if you try to view the item normally in JSPUI or XMLUI [ 4:36pm ] mdiggory : kshepherd: I understand and agree [ 4:36pm ] kshepherd : so there's even an implication, from a page that informs the browser the item is "restricted", taht they shouldn't be able to see the metadata [ 4:37pm ] DuraLogBot joined the chat room. [ 4:37pm ] DuraLogBot : This channel is logged - http://duraspace.org/irclogs/ [ 4:37pm ] mdiggory : perhaps there should be authorization in front of the uri [ 4:37pm ] kshepherd : but i agree it's a part of a much larger issue [ 4:37pm ] stuartlewis : So maybe skip it for 1.6, and add it as a central issue for whatever comes after the 1.6 branch? [ 4:37pm ] mdiggory : I'd say if kshepherd sees a solution... feel free to approach it [ 4:37pm ] mhwood : Agree, I don't think there's time for 1.6. [ 4:37pm ] kshepherd : i'm guessing that's how the voting will go, yeah just wanted to get some feedback on the whole "open access vs OPEN access" thing thanks [ 4:38pm ] bradmc : Yes, it seems late in the day to get a good solution for 1.6, but if Kim comes up with a miracle we can revisit. [ 4:38pm ] cwilper joined the chat room. [ 4:38pm ] mdiggory : authorization in front of /metadata/handle/xxxxxx/mets.xml shouldn't be a difficultly [ 4:38pm ] bradmc : cwilper: Thanks for log bot fix. [ 4:39pm ] mhwood : Hmmm, well, if this aspect can be fixed now, great, but the larger question is going to take some time. If we have access controls at all they should be consistent (whatever that means) across all access modes. [ 4:39pm ] cwilper : np, will robustify it soon [ 4:41pm ] [16:39] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer)) [16:40] * grahamtriggs (n=graha...@cpc3-stev1-0-0-cust857.lutn.cable.ntl.com) has joined #duraspace [16:40] <kshepherd> yep, that's a quick specific solution for that particular one [16:42] <kshepherd> brad's gone.. who's backup mod? ;) [16:42] <grahamtriggs> no-one. anarchy... ANARCHY!!!! [16:42] * kshepherd starts looting [16:42] <bollini> sorry to go back to specific jira issue but I need to prioritize them so that I can fix the most relevant in time for 1.6 [16:43] <bollini> http://jira.dspace.org/jira/browse/DS-267 who agree with Larry comments? [16:43] <grahamtriggs> kshepherd: wouldn't bother. There's only a bot in the corner, and by the looks of it, it's a bit broken [16:44] <mdiggory> HandleAuthorizedMatcher... might need minor surgery to support /metadata/handle uri [16:44] <rrodgers> bollini: I still feel this is not the best approach to influencing policy by submitter [16:45] <jat_ysu> Admins really don't want submitters changing a policy on the fly. [16:45] <bollini> rrodgers: I could agree... but this is mainly a fix for withdrawn item [16:46] <mdiggory> I agree [16:46] <mdiggory> with jat_ysu [16:46] <bollini> :-( [16:46] <rrodgers> bollini: as for withdrawal, I agree it's not perfect, but is this a big problem? [16:47] <mdiggory> but... we actually do have a case where we want the user to select from several permissions profiles... [16:47] <mdiggory> during the submission process [16:47] <mdiggory> we are not using DEFAULT_XXXX for this however [16:47] <jat_ysu> Okay, in that case you need to be able to insulate users from having that option as a default option. Perhaps only certain authorized users. [16:47] <kshepherd> bah, no solr books on our safari bookshelf :( [16:47] <rrodgers> yes, I think allowing entry of instructions or preferences is fine [16:47] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace [16:48] <mdiggory> kshepherd: I'll send you a url... [16:48] <grahamtriggs> jat_ysu: but when the submitter is an admin.... besides, if you want embargoes, then you are ceding (a certain amount of) policy control to the submitter... oh, the tangled web we weave... [16:48] <bollini> rrodgers: no really... (withdrawn) [16:48] <jat_ysu> User A is able to submit and make changes to collection 45, but User B can only submit to Collection 45, but not change. [16:49] <mdiggory> grahamtriggs: sure.. you do, but its controlled [16:49] <jat_ysu> Well, I'm the only admin who submits, but we have 45 other submitters who are not admins. [16:49] <mdiggory> I just don't think those "Actions" should be bastardized in that way... we need better controls than that... [16:49] <bollini> jat_ysu: this is more a question about UI... the DS-267 give us a place where store this data [16:50] <mdiggory> permissions templates [16:50] <grahamtriggs> is there really any reason why we don't just assign policies at the point of creation - and then have whatever *controlled* means of affecting them that we choose? [16:50] <rrodgers> bollini: also look at the Embargo as a model, you can enter metadata that the system interprets as policy [16:51] <rrodgers> in a controlled way [16:51] <mdiggory> rrodgers: is the policy applied when the metadata is entered... or on archiving of the item? [16:51] <bollini> collection A: open access, embargo (starting date), restricted access to a specific group - collection B: no option all open access - collection C: no option all restricted, etc. [16:51] <rrodgers> on installation - before that the policy means nothing [16:52] <mdiggory> k [16:52] <bollini> using metadata we have issues to manage policy on a bitstream basis [16:52] <mdiggory> oh how InstallItem needs plugability... [16:52] <jat_ysu> Okay, I see where you are going....there are already "pre-determined" policy choices for the submitter? [16:53] <rrodgers> mdiggory: Embargo does just that [16:53] <mdiggory> :-) [16:53] <mdiggory> commit IT! [16:53] <rrodgers> ;) [16:53] <jat_ysu> bollini:? [16:53] <bollini> jat_ysu: yes [16:53] <jat_ysu> And configurable? [16:54] <jat_ysu> If so, I endourse your proposal. [16:54] <bollini> I'm working on... [16:54] <jat_ysu> It still leaves control in the hands of the admins, and the submitter can just make lousy choices. [16:54] <jat_ysu> can=cannot [16:54] <mdiggory> rrodgers: you have the force... use it wisely ;-) [16:55] <rrodgers> mdiggory: cool [16:55] <jat_ysu> <== wants to use Sith Lightenting.... ;-) [16:55] <bollini> just to be more clear ds-267 is not against the rodgers embargo [16:56] <bollini> I have asked for comments because (as Larry as underlined) it makes the policy system more "confusing" [16:57] <jat_ysu> Well, it does, but a good understanding/grasp of what this option gives use should make it less of a problem. [16:57] <jat_ysu> I think in general the whole Policy issue is undaunting for the neophyte admin with dspace. [16:58] <rrodgers> bollini: I have to think about lcs proposal a bit more [16:59] <bradmc> Well, I came back from my alternate reality (should have known you guys wouldn't really go that silent), but I have a hard stop on these 20:00 GMT Weds. As per usual, please continue as you see fit, preferably with a minimal amount of looting, and no fires, lightning or otherwise. [16:59] <bollini> well... I will wait for your comments, if you want I will go ahead to develop the UI with configurable choices for the submitter [17:00] <jat_ysu> IMHO, it might be worth seeing it in action/testing. [17:01] <bollini> now, I need to prioritize my tasks for 1.6 (to be able to meet the deadlines) [17:01] <bollini> http://jira.dspace.org/jira/browse/DS-236 [17:01] <bollini> http://jira.dspace.org/jira/browse/DS-267 [17:01] <bollini> http://jira.dspace.org/jira/browse/DS-270 [17:01] <bollini> please give me your opinions [17:02] <rrodgers> Id say start with 270, which is your work, yes? [17:03] <bollini> yes it is an abstraction [17:03] <stuartlewis> Yes, 270 [17:03] <rrodgers> there may be assistance for 236 in time [17:03] <stuartlewis> Will 236 be ready for 1.6? [17:03] <bollini> 236 is a big task [17:03] <stuartlewis> (e.g. two week deadline) [17:04] <bollini> all the code xmlui/jspui/postgres/oracle is in the sandbox [17:04] <stuartlewis> Is it all tested and working, or is there lots left to do? [17:05] <bollini> well... I have tested a lot the jspui/postgres implementation but on a 1.5.0 installation [17:06] <bollini> the 1.6 porting has been make on the fly and I have done only a fast run on it (all seems to work) [17:07] <bollini> there is also a lot of work to do on the i18n [17:10] <mhwood> We need to find some "language wranglers" who can drive i18n development and maintenance. The skill set is different from most coding. [17:10] <stuartlewis> Would you feel more comfortable leaving it for after 1.6? [17:11] <bollini> most depend on the Larry availability [17:12] <bollini> I think that it will be really a big new feature and most people will love it [17:13] <bollini> but if I have to address the other two jira issues I have only marginal time for it (so only assistance not drive) [17:14] <stuartlewis> Maybe we should see how time goes over the next two weeks, and at the end of the month make the final call for what will, and what will not, be in 1.6? [17:14] <bollini> fine [17:14] <mhwood> Yes [17:15] <stuartlewis> Would be great if all these big features could get in, but if we don't make a final call at some point, we'll never get the release out. [17:16] <mhwood> Must go, thanks everyone! [17:17] <stuartlewis> Same here. Time to formally wrap up, or anything else to talk about? [17:17] <bollini> my primary concern is TESTING we need to make wide testing before release [17:17] * mhwood (i=mw...@mhw.ulib.iupui.edu) has left #duraspace [17:18] <stuartlewis> Yes. Ideally I'd like to see us freeze at the end of the month, two weeks of testing / getting the build sorted etc, then a release candidate + LiveCD (for testing) at the DSUG in mid-October [17:18] * jat_ysu (n=jeffr...@pool-70-20-82-37.pitbpa.east.verizon.net) Quit ("Leaving") [17:19] <bollini> ok, see what happen in the next weeks... [17:19] <rrodgers> Must also go - but I'd say there are a lot of goodies in 1.6 already, so we should err on the side of testing/stability [17:20] <kshepherd> indeed [17:20] * rrodgers (n=rrodg...@18.111.15.222) Quit () [17:21] <stuartlewis> Maybe leads us to a 1.7 in Spring 2010? :) [17:22] <kshepherd> hmm, my current contract won't have long to go by then ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
