Below is the transcript of a committer's meeting held on #dspace at irc.freenode.net at 20:00 GMT on April 14.
We intend to hold the next meeting, on #dspace at: April 22nd at 09:00 PDT / 12:00 EDT / 16:00 GMT / 17:00 CEST / 18:00 CEST / 04:00 NZST Anyone is welcome to attend. Meeting Summary: We discussed Mark Diggory's proposal to move SVN from Sourceforge to OSUOSL, which is gaining momentum. Testing of the platform will be occuring over the next week, and we will further discuss the timing and implementation of a move at a future meeting. IRC Transcript: <bradmc> What would folks like to discuss today? Let's seed a topic list. <rrodgers> Is 1.5.2. in the can? <bollini> only if you have good thing to say :-) <mdiggory> depends which can your referring to. <rrodgers> Sorry - I meant the film analogy ;) <mhwood> /\/\/\ <bradmc> 1.5.2 is at SF now. <mdiggory> and in the maven repo... I'm testing builds against it <rrodgers> So do we need to discuss any promotion or other outreach? *** mdiggory_ [n=mdigg...@cpe-76-176-188-137.san.res.rr.com] has joined #dspace <mdiggory_> lovely internet connectivity <bradmc> Foundation will be updating website, and sending news items. Andrea will announce. We can discuss beyond that. <mdiggory_> I'm happy with it and consider it "in the can" <bradmc> Also, possible continued discussion on 1.6, or Mark's proposal to move from SF to OSUOSL soonish. <bollini> should we talk about the OSL service? <bradmc> :) <rrodgers> Then many thanks to Andrea and Mark! <mdiggory_> ok <tdonohue> OSL sounds like a logical topic <mdiggory_> thanks rrodgers <ClaudiaJuergen> right, thanks to Andrea and Mark, that was a lot of work <bradmc> Hear Hear! Thanks! <mdiggory_> :-) <mhwood> [applause] <bollini> well I can go out now :-) <mdiggory_> bollini: take a bow *** ben_atmire [n=ben_a...@62.235.148.191] has joined #dspace <mdiggory_> So, OSL has given us a Virtual Machine with SVN and TRAC allowing us to manage SVN repository permissions <mdiggory_> ATM one instance of TRAC can map permissions on one SVN repository <mdiggory_> managing users in TRAC and allowing the admin to manage thier acl on specific repository paths <mdiggory_> I recently mirrored the whole SF SVN repo there rather than splitting off the dspace2 project only <mdiggory_> https://dspace.osuosl.org/svn/bazaar/ <mdiggory_> and the trac is located at... <mdiggory_> http://dspace.osuosl.org/trac/dspace <bollini> how good are the bandwitch? sometime with SF it is tedious <mdiggory_> I believe OSU sits on Inernet2 backbone... <bradmc> SF is tedious on _good_ days. <ClaudiaJuergen> so we could manage the lang modules there, too? <mdiggory_> http://members.internet2.edu/university/universities.cfm#O <mdiggory_> Yes, we could manage the dspace-sandbox and possibly even the dspace-gsoc there as well <mdiggory_> Its a machine where we have a great deal more control over everything <ClaudiaJuergen> would be good, I'm a bit concerned about the split up of DSpace related sources <mhwood> Having multiple repo.s, each assuming it is the center, is not much fun. Consolidation sounds good. <tdonohue> it sounds like this is also potentially a place we could allow others to commit "modules" or "add-ons" which haven't officially been "accepted" into out-of-the-box DSpace <ClaudiaJuergen> good idea <tdonohue> (that was meant to be a question, mdiggory) :) <mdiggory_> correct tdonohue <tdonohue> cool <mdiggory_> At first the initial layout mirrors the SF structure. But I anticipate wanting to organize the project tree a little better to support seperate project spaces <mhwood> Please. <ClaudiaJuergen> not only for code but also for i18n parts which are not managed via the lang modules <mdiggory_> If you look at dspace-sandbox, there is an appropriate layout for seperately versioned svn projects <mdiggory_> http://dspace-sandbox.googlecode.com/svn/modules/ <mdiggory_> likewise, we originally did the dao and other prototypes here... <mdiggory_> http://dspace-sandbox.googlecode.com/svn/prototypes/ <mdiggory_> and there are some maven plugins that are part of the build process located in here.... <mdiggory_> http://dspace-sandbox.googlecode.com/svn/team/maven/plugins/ <mdiggory_> My hope is that this all can get consolidated <tdonohue> in my opinion, this all sounds great...so, what's the "catch"? :) <ClaudiaJuergen> amen <mdiggory_> what i18n parts are not in the lang modules ClaudiaJuergen <bollini> the email files for example <mdiggory_> tdonohue: all this and "more" for just the small price of... your soul! ;-) <ClaudiaJuergen> mdiggory: email templates, help, input-forms, etc <mhwood> With more projects standing shoulder-to-shoulder, navigation becomes more interesting. I don't think that's a very big "catch", though. <mdiggory_> oh yes, email files and the like... that needs some help doesn't it <ClaudiaJuergen> there have been some providing complete translations and there is no place to put them * mdiggory_ ponders what the catches are... <ClaudiaJuergen> apart from the wiki, which is not very good <tdonohue> noticing OSUOSL already has a very impressive list of groups they host: http://osuosl.org/services/hosting/communities <rrodgers> Hmm, so that does raise the question of email lists, etc What of those? *** mdiggory [n=mdigg...@cpe-76-176-188-137.san.res.rr.com] has quit [Read error: 110 (Connection timed out)] * mdiggory_ thinks... "with great power comes, great responsibility..." no, thats too cliche'" <bradmc> I'd like to move one facility at a time. <mdiggory_> bradmc: that brings up a good point <rrodgers> OK - so we need to think about the 'straddle' condition - any problems? <mdiggory_> My proposal was the following... <mdiggory_> 1.) existing dspace/tags stay at S.F. to be preserved there <mdiggory_> 2.) dspace/branches will get stale if they stay on SF and are not somehow synced <mdiggory_> 3.) dspace/trunk... well, I suspect we will be setting that off to the side, back into "prototypes" <mdiggory_> 4.) current 1.5.x branch will need to be copied onto trunk... <mdiggory_> these are just lightweight svn copies <mhwood> Internet 2: from here, traceroute goes to indiana.gigapop.net, to internet2.edu, to oregon-gigapop.net, to something called nero.net, then the echoes stop. Maybe osuosl.org is not on Internet 2. <mdiggory_> hmmm... <mdiggory_> http://www.mozdev.org/pipermail/mirrors/2008-April/000275.html <mhwood> There should be a big notice somewhere to remind everybody that "trunk" no longer means what it did. While most will understand, remembering is a different question. <mdiggory_> suggests otherwise <mhwood> Could be a transient condition. My result is not definitive. <mdiggory_> Ok, is not definitive. I see reference to OSL rolling its own bandwidth solution, unsure what that means. <ben_atmire> I just did a test checkout, got about 160 MB in less than a minute <tdonohue> in any case, it sounds like they would be more responsive to problems, than say sourceforge :) <bollini> Mark, will be possible to move also the maven repo on OSL? <mhwood> So speed is probably no worse, and control is definitely better? <mdiggory_> http://oregonstate.edu/~dolanj/projects/fiberproject/ <mdiggory_> OSL and other contracted QWest to build a better channel to I2 *** mdiggory [n=mdigg...@cpe-76-176-188-137.san.res.rr.com] has joined #dspace * mdiggory misses the days of University bandwidth... * mdiggory misses the days of University bandwidth... <rrodgers> Another issue much discussed is timing... <mdiggory> Yes, timing, I'm not as concerned with others about migrating the commitership just after the release <mdiggory> in fact, I'd rather see that happen before more work was done, IE 1.6 <mdiggory> because we just keep the tags on S.F. theres no concern about where to find the source for the 1.5.2 release etc <mhwood> A quick move will need fairly loud publicity, but I think that those most affected should be the ones most able to cope. <mdiggory> I tend to agree <rrodgers> mdiggory_: can we now (based on your test migration) all try the environment out? <mdiggory> Yes, you should be able to all create accounts in TRAC and email us to give commit rights <rrodgers> Who is administering? <ClaudiaJuergen> not only loud but precise, we need to have the community adopt the new stuff too <mdiggory> us meaning whoever wants to administer with brad and myself... <rrodgers> Then maybe we should all do some quick checkouts etc for bandwidth & reliability worldwide? <tdonohue> i'd be ok with moving relatively quickly, after some more of us have tried out the new environment.....that was one of my larger concerns <mdiggory> yes, I also need to test my latest svn dump restore to make sure we got everything right permissions-wise and having others test it would help <ClaudiaJuergen> tests would be good best at different times too, euro afternoon was always awful at SF <tdonohue> in addition, (WARNING: complete hypothetical follows)...suppose we discover a major (serious) issue in 1.5.2...my concerns are whether we'd be able to release a quick 1.5.3 (in such an unlikely scenario) while in the midst of a migration...that's why i suggested waiting a week or two <tdonohue> (but, that being said...i don't think that would happen....just want to cover our bases) :) <mdiggory> tdonohue: I suspect that would take precidence <tdonohue> yea...i'm just making it clear the reason behind my concerns for big changes around release time...i tend to be a bit more conservative at those times :) <mdiggory> we should make a good amount of time to get comfortable with OSL before a freeze/migration event <tdonohue> makes perfect sense <mdiggory> and at that point, there would be a S.F. dump / restore to OSL to bring it in sync and a "Freeze" of all commit rights on SF until then it is business as usual at S.F. <bollini> anyway the trunk in OSL will be the "old" 1.5.x branches... so we should be able to manage a 1.5.3 release also from OSL <ClaudiaJuergen> maybe in the meantime we should consolidate JIRA and the SF trackers, that's still needs some work and promotion <mdiggory> bollini: true <tdonohue> yes, in general, i was only pointing out that I wouldn't want to move completely to OSL until we have made sure there are no "glitches" in that new environment (e.g. will releases work the same, or will there need to be slight changes to release scripts, etc.) <mhwood> How long to verify that? *** mdiggory_ [n=mdigg...@cpe-76-176-188-137.san.res.rr.com] has quit [Read error: 110 (Connection timed out)] <mdiggory> its just filtering the poms for the svn location <mdiggory> not a big project at all <tdonohue> yea...i doubt it'd take that long..I was just suggesting a few weeks buffer (just in case) between 1.5.2 and migration to OSL....but, if other's disagree, that's fine <mdiggory> we have all kinds of opportunities to use the OSL services for maven repos, testathon instances, etc <mhwood> Sounds like the questions would be answered in hours. Weeks seems excessive. <bollini> just noting that the OSL SVN version is 1.4.2 rather than the 1.5.3 of SF *** mdiggory_ [n=mdigg...@cpe-76-176-188-137.san.res.rr.com] has joined #dspace <tdonohue> "weeks" go back to my being conservative around release times....making sure our release scripts still work is only a hypothetical "glitch"...who knows what could come up :) <mdiggory_> did I miss anything... <ClaudiaJuergen> most probably it will take longer to point to the OSL at all the right places, wiki, docs *** stuartlewis [n=stuar...@gendig21.lbr.auckland.ac.nz] has joined #dspace <mdiggory_> So, we are also setting up the following vhost... <mdiggory_> http://scm.dspace.org <mdiggory_> to point at the svn repo <ClaudiaJuergen> morning Stuart <mdiggory_> note, we have an opportunity to adjust this url to our liking before any official move. <mdiggory_> https://scm.dspace.org/svn/bazaar still needs a vhost entry in the httpd on that machine <mdiggory_> so it doesn't work yet <mdiggory_> I'm trying to get it trimmed down via the httpd config to just be https://scm.dspace.org <bollini> mark: are you hiding in the vhost name an attempt to change the scm tecnology? you are a dangerous man :-) <rrodgers> bollini: Google code is using 1.4.0, for comparison <mdiggory_> OOOGGHhhaahahahahaha <mdiggory_> ok, on a more serious note, we are going on the 1hr mark <bollini> rrodgers: we should take care of that, because during the 1.5.2 release we have had some issue with maven-release plugin and svn *client* version <mdiggory_> do we have other agenda items? <mdiggory_> OSL is svn 1.4.2 <mdiggory_> SF is 1.5.5 <rrodgers> So maybe we should all try out OSL & compare notes next mtg? <mdiggory_> there are some features in 1.5.5 I was interested in on the server side, but it increases the complexity of maintaining the OS if they hand-roll the svn service independent of CentOS's <ClaudiaJuergen> sounds good <mhwood> ?? I see tag 1.5.1 just fine at OSL. What do I not understand here? <mdiggory_> mhwood: problem <mdiggory_> ? <tdonohue> i don't have anything else...and i'm heading out of here shortly for a 1 1/2 week vacation :) <ClaudiaJuergen> tdonohue: enjoy it <mdiggory_> mhwood: this is not the final state for that svn repo, just a stale copy from last week <mhwood> Pardon, that's the *SVN* version, not DSpace, isn't it. Oops. <mdiggory_> mhwood: crossed lines... yes, svn version <mdiggory_> tdonohue: smart man! <tdonohue> yes...I'll leave all the OSL final decisions to you all, while I'm off not thinking about it at all <bradmc> As mdiggory pointed out, we've passed the one hour mark; Seems like we always do, so maybe future should schedule for 90 min. <bradmc> But for today, wind down. <ClaudiaJuergen> good, definetly bed time <ClaudiaJuergen> good night all <rrodgers> night <mdiggory_> I should cut things short as there are always other things to get done <bradmc> Thanks all. <tdonohue> bye all *** ClaudiaJuergen [n=mira...@i5e86bc80.versanet.de] has quit ["Miranda IM! Smaller, Faster, Easier. http://miranda-im.org";] <mdiggory_> productive meeting... thanks <mhwood> 'bye all. <rrodgers> bye all <mdiggory_> bye ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Dspace-commit mailing list dspace-com...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-commit ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
