Timestamps are in GMT/BST.
[7:10] * cbeer_ (n=chris@dsl092-069-087.bos1.dsl.speakeasy.net) has joined #duraspace
[7:10] * cbeer_ (n=chris@dsl092-069-087.bos1.dsl.speakeasy.net) Quit (Remote closed the connection)
[7:15] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:03] * awoods (n=awoods@pool-71-191-160-158.washdc.fios.verizon.net) has joined #duraspace
[8:05] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
[8:30] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[9:10] * bradmc (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) has joined #duraspace
[10:03] * bradmc_ (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) has joined #duraspace
[10:03] * bradmc (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) Quit (Read error: 54 (Connection reset by peer))
[10:48] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has joined #duraspace
[11:58] * ysu_jat (n=jeffreyt@MAAG127.MAAG.YSU.EDU) has joined #duraspace
[12:00] * tdonohue (i=80ae241d@gateway/web/freenode/x-kvmrwxwvugxjjrjy) has joined #duraspace
[12:01] <bradmc_> Hello all, we're going to have a DSpace Committer's meeting here. If you have a topic of interest, please raise it and we'll sort out what to chat about today in a few minutes.
[12:05] <bradmc_> Do we have enough for a quorum today?
[12:07] <mhwood> Dunno, how many is that?
[12:09] <bradmc_> More then you, I, Tim, and Jeff, I suspect, although I'm happy to go ahead.
[12:10] <bradmc_> Did folks see MarkD's email about potentially setting up an apache style PMC, meeting at DSUG, services for 1.6, and modularizing?
[12:11] <mhwood> I have a copy right here.
[12:13] <bradmc_> Also, in a related topic to modularizing, the dspace staff at MIT is experiencing some pain from Maven when trying to maintain a local version of dspace. I expect them to report on it soon (guess it won't be today), but I'm curious if other folks are having troubles with the structuring of our POMs, and if they've developed any practices to solve them.
[12:14] <bradmc_> Having a leadership / PMC discussion with just a few people is likely doomed to failure, but if you have opinions for the record, you could toss 'em out. I'm sure MarkD will read the transcript.
[12:14] <ysu_jat> POMS are a problem for me...when I changed, for example postgresql jars, maven versions, or other tertiary programs that might be newer than the dspace distributed poms.
[12:15] <ysu_jat> It's just there's no documentation (did I say that) to give instruction regarding the POM and how to make things work.
[12:16] <mhwood> Oh, yes, there's lots of Maven documentation but it's still extraordinarily difficult to pin down the answers to a lot of everyday questions.
[12:17] <bradmc_> Yes, we seem to be missing some models for the common things that organizations do (develop on bleeding edge; maintain a trailing edge production version; carefully migrate specific pieces to local test site; issue quick trivial patches, ...)
[12:17] <mhwood> ..apply quick trivial patches...
[12:17] <ysu_jat> I think it would be helpful to document some of the dependencies that are called by Maven and the POM and what to do if you need/want to change them for your needs.
[12:18] <bradmc_> MIT has some interesting use cases; I'll leave it to them to submit their writeups when they're ready. Just wanted to confirm my hunch that this will be a topic of wide interest.
[12:18] <ysu_jat> IMHO its the dependencies that a problem, not the updates/patches......
[12:18] <ysu_jat> Well, the whole implementation of maven is not for the feint-hearted and I think that is what has caused folks not to upgrade to 1.5 as of yet.....
[12:19] <tdonohue> I'm just re-reading MarkD's email...I'd be open to the idea of such a committee and discussing it further...though I'd argue that it may be more worthwhile to have interested non-developers also sit on this committee (to help in deciding the direction of development work, etc.)
[12:19] <ysu_jat> If we could create an online tutorial for upgrading to 1.5 or installing 1.5 with the maven...it might really be helpful.
[12:20] <tdonohue> though, maybe that's another committee altogether....depending on if this PMC group is really *just* about managing code/releases in a more structured fashion
[12:20] <mhwood> I'm still trying to work out more precisely what the committee would do.
[12:22] <tdonohue> mhwood...i'd agree, and i'm also trying to work out if we truly have enough consistently active developer folks to form such a committee...
[12:24] <bradmc_> I suspect that's part of MarkD's thinking; since we fail to have enough committers engaged regularly to set a technical direction, the PMC mechanism would serve to get a group, er, committed to doing that. I haven't developed an opinion on that yet.
[12:27] <mhwood> Maven: I thought that the install/upgrade documentation was fairly clear, *for a vanilla DSpace*. There's some material about how local mod.s have moved into dspace/modules, but I could do with a bit of exposition on the finer structure of the project tree, where specifically various bits need to go in order to avoid massively distorting the dependencies and suchlike.
[12:27] <bradmc_> Shifting to another topic involving committed committers, it will be time to find a post-1.6 release coordinator soon, so please start thinking about that.
[12:27] <ysu_jat> The instructions are pretty clear, if you ignore the few typographical errors (which have been corrected).
[12:28] <tdonohue> i can understand that...I just am not confident that even this PMC mechanism can *keep* people committed to doing development work. I think the lack of commitment at times comes more from external workplace pressures (since we are all volunteers)
[12:29] <tdonohue> (or at least, that's why my commitment goes up and down at times....it basically depends on how much stuff I have on my plate at work, and how much time I can devote to volunteering for dspace.org)
[12:30] <mhwood> I dunno, I think that sometimes we have a problem in that responsibility is so diffuse. There's too little follow-up.
[12:31] <bradmc_> Yes; PMC members have terms, so we'd need to make sure our members could commit for the terms (possibily by manipulating the length of the terms).
[12:33] <bradmc_> Were there other topics of interest today?
[12:36] <mhwood> Hmm. A PMC could trawl the trackers and stir up interest in issues that are languishing. But that's backward-looking and we also need some forward-looking.
[12:38] <tdonohue> I didn't have anything else for the agenda... I definitely think the PMC idea would be worth discussing in much more detail at a meeting where we have a full quorum. It could be a way to better formalize things and keep us all on track...
[12:38] <mhwood> The technical direction of late has been set by a group that was off to one side, and the rest of the community has been free-running in various directions. We do need some machinery for pulling all those good ideas into an organic, evolving plan.
[12:40] <bradmc_> Good thoughts. Since the natural inclination will be to tackle this at DSUG, those who won't be there should scream loudly beforehand, either to dissuade or influence that conversation.
[12:40] <mhwood> One thing I like about the Fedora meetings is that it's clear that ideas are tracked and regularly raised until resolved.
[12:41] <bradmc_> Agreed. I'm hoping to do that with the issues review here, but haven't launched yet for two reasons: 1) our intern is out of the country, and 2) best launched when we have good attendance; tricky at high summer.
[12:42] <tdonohue> detailed discussion at DSUG sounds like a good idea...hopefully we can also set aside an IRC meeting (or a large chunk of one) for those who cannot make it to DSUG
[12:43] <mhwood> Topics: regression/integration testing?
[12:44] <bradmc_> Aside: DuraLogBot is at http://duraspace.org/irclogs/ although I'll still try to get summaries out to the mailing list with some regularity. It probably helps our attendance as well.
[12:44] <bradmc_> mhwood: go ahead
[12:44] <tdonohue> can we get that linked somewhere off the wiki? :)
[12:45] <bradmc_> tdonohue: Absolutely. We're shuffling infrastructure around right and left these days, so I'll try to make sure that we've got the final URL right first.
[12:47] * mdiggory (n=mdiggory@128.189.73.227) has joined #duraspace
[12:47] <mhwood> Testing: Um, we could use some? It's something I'd like to have and that I'd like to learn. I don't have anything more specific yet. Mainly I'm bugged that I've had to fix the same problem twice and want to start preventing that as I go.
[12:49] <tdonohue> mhwood: are you talking testing frameworks (like JUnit, etc.)...or just people actively pulling down code and testing things out (or both)
[12:49] <bradmc_> Three pieces to that, right? Choosing a testing framework, making sure something runs the tests regularly and/or local builds run tests, and having people write tests for things they want tested.
[12:49] <mhwood> The former. There was a brief exchange on Dspace-devel.
[12:50] <bradmc_> mdiggory: http://duraspace.org/irclogs/index.php?date=2009-07-29
[12:50] <mhwood> Maven will eagerly test anything you've written tests for.
[12:50] <bradmc_> (provided you make the accessible to Maven)
[12:50] <bradmc_> the = them
[12:51] <tdonohue> yep...for our local custom code, we use Maven + JUnit, which means everything is tested whenever you rebuild (assuming that JUnit scripts are built for everything, obviously)
[12:52] <mhwood> Framework: Maven likes JUnit but can be tuned for others.
[12:52] <tdonohue> and, i'd agree that it'd be nice if DSpace used a testing framework (whether its JUnit or not)
[12:56] <bradmc_> Given the disparate nature of the dspace components, I suspect we'll need more than one, for example JUnit and friends for pieces like dspace-api, but selenium or something else for UIs.
[12:56] <mhwood> As is usual for me, I started to learn this stuff on a case that poses significant challenges of its own: integration testing is hard to set up for DSpace because of all the database building and filling, and the amount of configuration needed. I don't yet have anything small and simple that I could just throw out as a quick start.
[12:56] * bradmc_ starts toying with the gavel
[12:57] * mhwood adds selenium to his reading list.
[12:58] <bradmc_> I have to head towards my next meeting, but as always, continue on as you see fit.
[12:58] <tdonohue> i'd say, use that gavel...there's only three of us talking right now...and we've definitely identified a few things to bring up again in the future (1) MarkD's PMC idea, and (2) testing frameworks
[12:58] <mhwood> The email exchange points out some other challenges w.r.t. testing. Maven already throws a lot of stuff at installers, and testing output adds significantly to that, in many shops perhaps unnecessarily.
[13:00] <mhwood> A motion to adjourn to informal discussion is made and seconded. OK by me.
[13:00] <tdonohue> true...it might be useful to "turn it off" by default.
[13:00] <tdonohue> ok, consider it adjourned then :)
[13:00] * bradmc_ hits his thumb with a hunk of wood.
[13:03] <mhwood> I'm about run down on testing for now. I just didn't want the idea to disappear.
[13:04] * ysu_jat (n=jeffreyt@MAAG127.MAAG.YSU.EDU) has left #duraspace
[13:20] * tdonohue (i=80ae241d@gateway/web/freenode/x-kvmrwxwvugxjjrjy) Quit ("Page closed")
[13:30] * gaurav_hiiii (i=d2d43dfb@gateway/web/freenode/x-dreehvcwlfwvivqx) has joined #duraspace
[13:32] * gaurav_hiiii (i=d2d43dfb@gateway/web/freenode/x-dreehvcwlfwvivqx) has left #duraspace
[13:59] <ksclarke> does anyone have a sense whether that duracloud integration engineer position is located at Cornell, MIT, or could be remote(?)
[14:23] * bradmc_ (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) Quit ()
[14:24] * bradmc (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) has joined #duraspace
[15:08] * mdiggory (n=mdiggory@128.189.73.227) Quit ()
[15:19] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) has joined #duraspace
[15:20] * bradmc (n=bradmc@dhcp-18-111-6-157.dyn.mit.edu) Quit ()
[15:30] * bradmc (n=bradmc@JOHNSON-FIFTY-ONE.MIT.EDU) has joined #duraspace
[15:45] * bradmc (n=bradmc@JOHNSON-FIFTY-ONE.MIT.EDU) Quit (Read error: 60 (Operation timed out))
[16:02] * ksclarke (n=kevin@ip-152010148147.library.appstate.edu) has left #duraspace
[16:21] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:31] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit (Remote closed the connection)
[16:36] * mdiggory (n=mdiggory@128.189.255.88) has joined #duraspace
[16:53] * mdiggory (n=mdiggory@128.189.255.88) Quit ()
[17:02] * ksclarke (n=kevin@adsl-235-102-10.clt.bellsouth.net) has joined #duraspace
[17:09] * mdiggory (n=mdiggory@128.189.231.34) has joined #duraspace
[17:37] * mdiggory (n=mdiggory@128.189.231.34) Quit ()
[17:43] * mdiggory (n=mdiggory@128.189.231.34) has joined #duraspace
[17:51] * mdiggory (n=mdiggory@128.189.231.34) Quit ()
[18:12] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) Quit (Read error: 104 (Connection reset by peer))
[18:39] * stuartlewis (n=stuartle@gendig21.lbr.auckland.ac.nz) has joined #duraspace
[19:43] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ()
[23:37] * awoods (n=awoods@pool-71-191-160-158.washdc.fios.verizon.net) Quit (Read error: 110 (Connection timed out))
[23:47] * ksclarke (n=kevin@adsl-235-102-10.clt.bellsouth.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.