Timestamps are in GMT/BST.
[1:22] * bradmc (~bradmc@216.30.189.241) has joined #duraspace
[1:56] * benoitg (~benoitg@173.246.5.94) has joined #duraspace
[3:09] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[5:06] * bradmc (~bradmc@216.30.189.241) Quit (Ping timeout: 240 seconds)
[5:34] * bradmc (~bradmc@216.30.189.241) has joined #duraspace
[6:15] * sbayliss (bcde58ad@gateway/web/freenode/ip.188.222.88.173) Quit (Ping timeout: 252 seconds)
[6:33] -niven.freenode.net- *** Looking up your hostname...
[6:33] -niven.freenode.net- *** Checking Ident
[6:33] -niven.freenode.net- *** Found your hostname
[6:33] -niven.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) Quit (Ping timeout: 260 seconds)
[6:38] * Disconnected.
[6:38] -verne.freenode.net- *** Looking up your hostname...
[6:38] -verne.freenode.net- *** Checking Ident
[6:38] -verne.freenode.net- *** Found your hostname
[6:38] -holmes.freenode.net- *** Looking up your hostname...
[6:38] -holmes.freenode.net- *** Checking Ident
[6:38] -holmes.freenode.net- *** Found your hostname
[6:38] -holmes.freenode.net- *** No Ident response
[6:38] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:38] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:38] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:14] * bradmc (~bradmc@216.30.189.241) Quit (Quit: bradmc)
[12:14] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[12:44] * bradmc (~bradmc@137.54.31.232) has joined #duraspace
[12:44] * benoitg (~benoitg@173.246.5.94) Quit (Read error: Connection reset by peer)
[12:56] * benoitg (~benoitg@173.246.5.94) has joined #duraspace
[13:29] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:50] * sandsfish (~sandsfish@18.111.25.122) has joined #duraspace
[15:54] * sandsfish (~sandsfish@18.111.25.122) Quit (Client Quit)
[16:02] * sandsfish (~sandsfish@18.111.59.30) has joined #duraspace
[16:15] * grahamtriggs (~trig01@62.189.56.2) has left #duraspace
[16:23] * sandsfish_ (~sandsfish@18.111.59.30) has joined #duraspace
[16:25] * sandsfish (~sandsfish@18.111.59.30) Quit (Ping timeout: 260 seconds)
[16:25] * sandsfish_ is now known as sandsfish
[17:03] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Remote host closed the connection)
[17:11] * benoitg (~benoitg@173.246.5.94) Quit (Remote host closed the connection)
[17:11] * benoitg (~benoitg@173.246.5.94) has joined #duraspace
[17:23] * benoitg (~benoitg@173.246.5.94) Quit (Remote host closed the connection)
[17:25] * benoitg (~benoitg@173.246.5.94) has joined #duraspace
[17:26] * benoitg (~benoitg@173.246.5.94) Quit (Client Quit)
[17:41] * bradmc (~bradmc@137.54.31.232) Quit (Quit: bradmc)
[17:42] * sandsfish (~sandsfish@18.111.59.30) Quit (Quit: sandsfish)
[18:17] * snail (~yeatesst@130.195.179.88) Quit (Ping timeout: 260 seconds)
[18:30] * snail (~yeatesst@130.195.179.88) has joined #duraspace
[19:20] * sandsfish (~sandsfish@18.111.25.122) has joined #duraspace
[19:37] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:38] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[19:43] * mhwood (~mhwood@adsl-99-162-50-38.dsl.ipltin.sbcglobal.net) has joined #duraspace
[19:44] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) has joined #duraspace
[19:45] * JRhoads (~jrhoads@160.10.15.22) has joined #duraspace
[19:45] * PeterDietz (~PeterDiet@sul272peter.lib.ohio-state.edu) has joined #duraspace
[19:50] <tdonohue> Reminder all, Special Topics Mtg today for our DSpace Developer Mtg (starts in about 10min). If you haven't already, please review the wiki pages linked from the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-04+-+Async+Releases+and+Trunk+Reorg
[19:50] <kompewter> [ DevMtg 2011-05-04 - Async Releases and Trunk Reorg - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-04+-+Async+Releases+and+Trunk+Reorg
[19:52] * bojans (~Bojmen@91-118-63-172.dynamic.adsl-line.inode.at) has joined #duraspace
[19:55] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) has joined #duraspace
[19:58] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[19:59] * keithgilbertson (~keithgilb@207.138.47.158) has joined #duraspace
[20:01] <tdonohue> Hi All, it's that time again. Today's meeting is a Special Topics Mtg on Async Releases & Trunk Reorg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-04+-+Async+Releases+and+Trunk+Reorg
[20:01] <kompewter> [ DevMtg 2011-05-04 - Async Releases and Trunk Reorg - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-05-04+-+Async+Releases+and+Trunk+Reorg
[20:01] <tdonohue> I just added several *questions for each of us to answer* to the top of our agenda. This is what I'd like to go through today, to try and keep the discussion on track and moving along
[20:02] <tdonohue> So, without further ado, my first question for everyone is this:
[20:02] <tdonohue> 1. What are your responses to each of these ideas/proposals? Do you have questions/concerns, agree/disagree, or have alternative ideas?
[20:02] <tdonohue> the proposals I'm referring to are the ideas from mdiggory & I around Async releases & trunk Reorg: https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release and https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release+-+Alternative+Option
[20:02] <kompewter> [ Asynchronous Release - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release
[20:02] <mdiggory> Wow, that'll take me quite a bit of time to respond to ;-)
[20:02] <kompewter> [ Asynchronous Release - Alternative Option - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release+-+Alternative+Option
[20:03] <grahamtriggs1> I have three main concerns that I want to see satisfied:
[20:03] <tdonohue> yea, i realize this is a big question, but it's a place to start
[20:03] <grahamtriggs1> 1) The effort involved in rolling an 'official' release
[20:03] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:03] * mdiggory hand the mike to grahamtriggs1 ?
[20:03] <mhwood> Well, I still want to know how to respond when someone asks me which version of DSpace I'm running, if a dozen bits all have their own versions.
[20:03] <grahamtriggs1> 2) visibility of ALL the code that goes into an official release
[20:04] <mhwood> +1 visibility of all code
[20:04] <tdonohue> sure, lets all start with handing mike to grahamtriggs1 and his concerns
[20:04] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:04] <grahamtriggs1> 3) the ability / effort involved in creating 'source drops' or local backups of the official release code, that as an implementor we use as the basis of a providing a service
[20:05] <robint> Can you expand on point 3? Dont quite understand
[20:05] <mdiggory> (1) Rolling the release involves releasing or using currently released versions of all included modules. The release process would still be similar, but the code would come from multiple locations. I assume we should be able to attain a distribution that still carries all the source in its current form...
[20:06] <mdiggory> as anassembly process
[20:06] <tdonohue> i agree with robint -- don't understand #3 point entirely
[20:06] <mdiggory> though, I would personally shy away from it
[20:06] <mdiggory> which also clarifies (2)
[20:07] <grahamtriggs1> ok, if you were creating a customized version of an open source project, 'best practise' is to take the base code and create a tagged 'vendor drop' in your local source repository (see SVN book on vendor drops)
[20:07] <mdiggory> likewise, releases should depend entirely on MAven Central repository Releases and as such, the javadoc and source jars should be released in concert with modules release processes
[20:07] <robint> grahamtriggs: ok, understood
[20:08] <tdonohue> as for grahamtriggs #1 point, I agree with the concern around avoiding making releases too complex. I wouldn't want a release coodinator to *ever* have to perform releasing of many different modules one-by-one before he/she could package up the formal release.
[20:08] <grahamtriggs1> even if you aren't customizing, it's still good practice to maintain a 'local' copy of the source code that you were working with (just in case anything ever happened with the main repository, or you had to deal with a period without internet access from your dev environment, etc.)
[20:08] <mdiggory> To be clear, we don't actually use vendor branching in @mire. So we do not have a need there
[20:08] <tdonohue> I also now understand #3, thanks grahamtriggs1. I thought you were talking about "vendor drops" but it wasn't clear at first
[20:09] <mhwood> We do vendor branching here, however.
[20:09] <tdonohue> I used to do vendor branching at U of Illinois -- so I am aware that many folks do vendor branching
[20:10] <mhwood> We tried putting our modified JSPs in local/ or whatever and the upgrade was awful. I am so thankful to have tools to help me keep the merging straight.
[20:10] <mdiggory> Likewise, I used it at MIT, but moved us away from it when Maven was adopted
[20:11] <tdonohue> Ok, one thing I will state is that my concerns parallel graham's, especially his #1 (minimizing release effort) and #2 (ensuring all code is visible). I still don't quite grasp mdiggory's answers to either of these
[20:11] <mdiggory> We focused on getting away from low level sourcecode management as a means to support a production instance
[20:11] <mdiggory> And I continued that model into @mire
[20:12] <robint> Re. point 1, my understanding of mdiggory proposal is that in some respects a 'dspace project' release would in some respects be simpler in that unchanged modules would not be released eg. LNI ?
[20:12] <mdiggory> likewise, tdonohue I recall you moved IDEALS away from that approach as well
[20:13] <grahamtriggs1> I think avoiding low level sourcecode management is a good thing in general - but I still see it as beneficial to base off of your own copy of the source / artifacts. It means you can incorporate - or develop - solutions to local problems ahead of them being available in an 'official' release
[20:13] <mdiggory> But even though my position differs from Graham, I do support is right to have vendor branching options available
[20:14] <mdiggory> so, its sounds like we need to consider the two cases as requirements
[20:14] <mdiggory> robint: correct
[20:14] <tdonohue> I think the vendor drop/branching thing is something that is not really the *root* question here (would like to set that aside for now, unless others disagree). I feel that Graham's #1 and #2 questions are some of the *root* concerns here.
[20:15] <mdiggory> robint: but even more-so, if you don't want LNI in your release you can disable it without carrying around all its code...
[20:15] <tdonohue> (i.e. we can figure out vendor drop/branching later -- it seems "solvable" once we figure out the other questions)
[20:15] <mhwood> I think what we wind up with is a tree of releases. Each project releases to the projects that use it. At the top is "DSpace", whatever that is now.
[20:16] <mhwood> There was discussion on #dspace the other day about "project" releases and "product" releases.
[20:16] <mdiggory> mhwood: that is true... and we do need to assure that the source for the all the parts is readily available and resolvable
[20:16] <tdonohue> so, to counter robint's point -- what if we added new features to DSpace that now need to "bubble up" to most every UI. Does that mean a *separate* one-by-one release of XMLUI, then JSPUI, then SWORD or LNI (if affected), then finally the full release?
[20:17] <mdiggory> but that doesn't mean having to build it everytime you build deploy dspace
[20:17] <mhwood> Ah, source visibility...I hate looking into a stack dump and wondering, org.dspace.whozit.Thing...where is that...it's not *anywhere*! [thinks for a while] Oh, yeah, it's probably in another module that I don't even have loaded into Eclipse.
[20:18] <robint> Actually tdonohue I had a similar quetion for you :)
[20:18] <mdiggory> mhwood: m2eclipse and IDEA will resolve those sources for you
[20:18] <mdiggory> as long as theya re in the maven repo
[20:19] <mhwood> And as long as my IDE even has them checked out somewhere.
[20:19] <robint> mdiggory: but they wont appear in searches etc in your IDE
[20:19] <robint> unless they are checked out
[20:19] <mhwood> Exactly! "Go there...show me" doesn't work.
[20:19] <mdiggory> tdonohue: I assume this is a dependencyManagement issue in maven, where the appropriate versions of dependencies would be defined and adusted for the "Product Release"
[20:20] <grahamtriggs1> but the issue of whether you 'carry' the source code of an unwanted project is only really an issue in the vendor drop scenario, and doesn't have much to do with sync / async releases... as in, I can do a sync release of all projects, deploying the artifacts to Maven central, but an implementor is only going to pull back the ones that they've got referenced in their local assembly.
[20:20] <mdiggory> robint: it depends on how you tailor your search, IDAE does traverse the maven sources
[20:21] <robint> mdiggory: Ah, looks like I need to do some homework
[20:21] <mdiggory> grahamtriggs1: so that suggests a source assembly from maven source artifacts
[20:21] <mdiggory> that would be the output for a vendor drop...
[20:21] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[20:21] <tdonohue> mdiggory ?? not sure I understand your answer to my question. my point is *someone* has to release a new version of each UI (or each project/module that is affected when there's a core API change). So, if 10 modules are affected, does that somehow mean the RC is doing 10+ releases rather than 1?
[20:22] <mhwood> No, they release when they are ready.
[20:22] <mdiggory> grahamtriggs1: but I already know what your going to say... how did you know I would knock over the vase?... sorry, what about the versionhistory...
[20:22] <robint> tdonohue: Would that not be the case in the case of a project release in your alt proposal ?
[20:23] <tdonohue> mhwood - so, define "ready" (undergone a testathon? or they release *after* the core release?)
[20:23] <robint> The modules are only going to be referenced as dependencies, rather than living in trunk, so would need to be individually released (I think)
[20:23] <tdonohue> robint -- yea, I'm actually also pointing out flaws that would also affect my alt proposal -- I just feel my alt proposal decreases the number of maximum releases at once to ~5-6, instead of many more
[20:24] <robint> :)
[20:24] <mdiggory> tdonohue: I guess the question is how much should the release process act as a shepherd for less popular subprojects?
[20:24] <mhwood> When the LNI packaging team thinks LNI version.next is good enough for general realease, they release it. Next time the "boxed DSpace" team is building a release they try using this latest version, and if it works well, that's the one they package.
[20:24] <grahamtriggs1> IDEs resolving the deployed source for a deployed artifact is not a sufficient answer to the question of visibility. The issue is not just about whether you can debug into the code, but whether anyone is looking over it before it's released.
[20:24] <tdonohue> It shouldn't be the "shepherd for *less popular* projects". But, it *should* be the shepherd for our core projects -- and if we separate into 10+ core projects, than that's still 10+ releases one-by-one
[20:25] <mhwood> Why one-by-one? Why all 10, if only 3 changed?
[20:25] <robint> mhwood: depends, in mdiggory proposal it wouldn't be released in a project release
[20:25] <mdiggory> tdonohue: your question is also answered in the Domain Model work... where the webapp relies on the API contract, which is published less often, while the assembly and integration test relies on the more apt to change implementation
[20:26] <mdiggory> so, no, LNI wouldn't need to be migrated to dspace-api-x.x, because thats mediated in assembly
[20:26] <tdonohue> If only 3 changes, than you are safe. I'm saying if we suddenly make a change to 'dspace-api' that needs to "bubble up" (and affects everything), then we've just made the RC's job on release day a lot harder
[20:27] <mhwood> Breaking contracts is a major version. That doesn't happen very often, and we can sneak up on it if the work is organized well.
[20:27] <mdiggory> perhaps we would need modules release coordinators to delegate the responsiblity...
[20:27] <mdiggory> mhwood: correct
[20:27] <tdonohue> (I'll note we have a hard enough time finding a single release coordinator sometimes -- how are we going to find modules release coordinators for each module?)
[20:28] <mdiggory> we already coordinate the release of dspace-services.... and learned some important requirements from Stuart Lewis / SWORD in the recent releases....
[20:28] <tdonohue> also, how do we ensure that each module is *well tested* for each and every release?
[20:28] <mhwood> Run the test suite?
[20:28] <mdiggory> namely that it is best to rely on dspace-services SNAPSHOTS in the trunk to verify the integration prior to release, that may be a better example than a webapp
[20:28] <robint> tdonohue +1
[20:29] <tdonohue> what test suite? (he asks slyly -- oh, sure, we have some minimal tests, but most modules have none)
[20:29] <mdiggory> dspace-services releases have their own suite of unit tests that it conforms to and has to pass in its releases
[20:30] <grahamtriggs1> additional to tdonohue's point - how do we ensure various combinations of different module versions are "well tested". And how do we express what is qualified to work with each other?
[20:30] <mhwood> Yes, however, other projects have not gotten as much attention of late.
[20:30] <robint> Backtracking for a moment, is there a demand as yet for async releases ?
[20:30] <mdiggory> I've been working to extend the existing test suite into the module addons so it can be run there as well... we need more UI /business logic tests (another reason to promote PeterDietz's activities
[20:30] <robint> As yet nothing is commited for 1.8 and we are already in May
[20:31] <tdonohue> grahamtriggs1 +1 unit tests are not always good at testing that modules will continue to "work well with others"
[20:31] <mdiggory> robint: What is working on still needs more stabilization before I commit it... (i.e. Domain Model work)
[20:31] <mhwood> That's called "integration test"
[20:31] <mhwood> Which we don't have yet.
[20:31] <tdonohue> right, and we don't have "integration tests" yet
[20:31] <mdiggory> thats right...
[20:32] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:32] <mhwood> We need to get our infrastructure in place before we charge over the async. release hill.
[20:33] <tdonohue> robint +1 as well -- in some ways, I understand the need for some async (like avoiding having to release *all* UIs in a final release perhaps), but what is the real use case. How truly "async" do we need to be, or is it enough to just async release the UIs?
[20:33] <mhwood> UIs are a good place to start. Then we evaluate the experience. If we see benefit in doing more, we do more.
[20:33] <mdiggory> We can almost get out of the Async release bind with Domain Model and Legacy Services... the original problem that cause the async release to emerge was a need for dspace-stats and dspace-discovery to rely on a released version of dspace-api while being used by a released version of dspace-xmlui-api.
[20:34] <mdiggory> this meant that to roll the release, we had to copy the source into the trunk...
[20:35] <mdiggory> while what was really wanted by myself and others was to keep it in modules, release it there and have the trunk depend on it
[20:36] <mdiggory> releasing the api separately and having external dspace-stats and dspace-discovery depend on it, the dspace-api version and dspace-xmlui-api versions can "slide freely" underneath it
[20:36] <grahamtriggs1> tdonohue: I'm not so convinced about the need for async release for UIs either. I mean, it can exist for 'unblessed' projects (such as it kind of does for webmvc in it's current state). But any UI that we badge as 'supported', people are going to expect to be released at the same time as the other projects.
[20:36] <mdiggory> because it doesn't actually depend on them...
[20:36] <tdonohue> So, twisting the question slightly: Would others agree that Async releasing of UIs *only* initially would be a good to try? Does this still throw up red flags for some?
[20:37] <tdonohue> (and grahamtriggs1 already answered my question -- what about others? what do you think?)
[20:37] <mhwood> Well, there's "released for integration" and "released to manufacturing".
[20:37] <mdiggory> I havn't pushed async release of the UI because its not a priority for me
[20:37] <richardrodgers> tdonohue: do you mean _multi_ releasing or releasing over time (asynch)?
[20:37] * barmintor (barmintor@specdl11.cul.columbia.edu) has joined #duraspace
[20:37] <mdiggory> its the supporting addons and service that I'm pushing using it for
[20:38] <tdonohue> richardrodgers -- I mean something similar to what I wrote up in my 'alt' proposal. Releasing the UIs in multiple during a full release, but having the *ability* to release them entirely separately as we see fit (for bug fixes, etc)
[20:38] <mhwood> So if we just rip the signatures off of dspace-api into a separate project full of interfaces, does that do what you want?
[20:39] <robint> tdonohue: that would concern me at this time. For users the UI is the app, so a new XMLUI is a release for them. Try explaining that its just an async release of one module
[20:39] <tdonohue> hmm...good point, robint
[20:40] <mhwood> robint: try telling them here's a new release of XMLUI with these nifty improvements *and you don't have to upgrade the rest of DSpace to use it*.
[20:40] <mdiggory> mhwood: its helps, but theres still a need for a means to get at the static CRUD methods... which requires the "Legacy" implementation of Repository/DAO services to support calling those methods.
[20:40] <mdiggory> and theres a need to extract a bit of XMLUI / Coocon Transformer support from dspace-xmlui-api
[20:41] <mdiggory> and creat api around that
[20:41] <robint> mhwood: touche :)
[20:42] <grahamtriggs1> mdiggory: but the problem with dspace-stats / dspace-discovery is that you are making the UI release depend on something that you are trying to manage as being an optional module. Either it *is* required, and therefore should be in trunk, or it's optional, which leaves it up to an end user to add the support to the UI
[20:42] <mdiggory> mhwood: robint: if our minor release cycles stipulate clear backward compatibility in configuration and api contracts... yes
[20:42] <mdiggory> you could do that
[20:43] <mhwood> Seems I'm always having this conversation: I want to break a big complex job into small easy stages and someone else keeps gathering it all back together.
[20:43] <mdiggory> grahamtriggs1: not scalable
[20:43] <tdonohue> So, what if we turn this around another way. "What belongs in main Trunk?" (i.e. what *really should* be released together all at once, synchronously), and "what really could/should exist 'outside' trunk (and therefore have the ability for async release, though not required)?"
[20:44] <mhwood> First, please don't call it Trunk. If we have twenty projects then there are twenty trunks.
[20:44] <grahamtriggs1> mdiggory: why? it's either required, or it's optional. Optional can grow as much as it likes. Required we need to keep a close check on.
[20:44] <tdonohue> for lack of a better term, I called it "main trunk", mhwood -- if you have something better feel free :)
[20:45] <mhwood> I've been thinking of it as "boxed DSpace" or the like. Something shorter needed.
[20:45] <mhwood> Anyway, the answer to your question is difficult, because the minimum includes one UI but not any particular one.
[20:46] <mhwood> I suppose it doesn't have to. That package could be "headless".
[20:46] <tdonohue> yea -- that's what I was wondering and asking myself -- could it be "headless", and just be a "core set of API modules"? Or is at least one UI required there?
[20:46] <richardrodgers> we should not forget there is great adopter value to whole (tested) systems, not bags of components
[20:47] <mdiggory> grahamtriggs1: I'm not going to reiterate the scalability concerns in scaling up a community on one svn repository trunk
[20:47] * keithgilbertson (~keithgilb@207.138.47.158) Quit (Ping timeout: 264 seconds)
[20:48] <mdiggory> tdonohue: its actually the "dspace-core" api contracts that need to reside outside the "main trunk" and the Legacy Service implementations that need to reside inside the trunk
[20:48] <tdonohue> richardrodgers +1 yea, most of our user base of 1,000+ institutions really just wants a whole (tested) system, and doesn't care about getting things async (unless maybe it's easy to install add-ons, which are not at all part of out-of-the-box DSpace)
[20:48] <mdiggory> tdonohue: to make the proposed domain model actually work
[20:49] <mhwood> One UI is requred to have something useful. ("UI" to me includes e.g. SWORD, and the REST thingy when it ships.)
[20:49] <mdiggory> I don't much care about the rest of trunk moving out these days... specifically I want to get those things that were in modules back into the modules management space
[20:50] <mdiggory> dspace-discovery dspace-stats, dspace-services and the future dspace-core api contracts
[20:50] <mhwood> But that doesn't have to be the way it's acquired. Unpack the core and your choice of UI(s).
[20:50] <mdiggory> all need to not be deadlocked to the release
[20:50] <grahamtriggs1> mdiggory: firstly, I don't get your point here. *only* the required stuff would need to be in 'one trunk'. Everything else can be wherever the hell it likes - but we can't include dependencies on it in the release. That's what it means to be optional. Secondly, making this an issue of SVN scalability is pre-empting the discussion about dvcs - if we were talking Git / GitHub, it completely changes the picture in dev
[20:50] <mdiggory> stats and discovery are optional
[20:50] <richardrodgers> I look to models like eclipse - essentially all compone nts - that offer a small number of hardened, tested configurations....
[20:51] <mdiggory> you can turn them on and off
[20:52] <grahamtriggs1> then there shouldn't be any references to them in the releases - it's up to end users to configure them. If you want them in the release, then they need to be treated as required (even if they can be disabled / re-configured)
[20:52] <mdiggory> dspace-services and core are not optional, but need to be released separate from the trunk for optinal addons to depend on fixed release numbers that would be used/incremented in trunk
[20:52] <richardrodgers> but with the ability *also* to grab add-ons as needed
[20:52] <mdiggory> grahamtriggs1: I just do not agree
[20:52] <tdonohue> +1 there's two definitions of "required": #1 "required" in that they are required to install (wheher you use them or not), and #2 "required" in that you cannot turn them off
[20:52] <mhwood> Our code shouldn't be so fragile that it depends on specific fixed releases of supporting code.
[20:53] <mdiggory> richardrodgers: bingo
[20:53] * JRhoads (~jrhoads@160.10.15.22) has left #duraspace
[20:54] <mdiggory> mhwood: depends on how well the supporting code is maintained
[20:54] <mdiggory> if ti changes dramatically over time, yea, it needs to be fixed releases
[20:55] <mhwood> If it breaks contracts then that's a new major release.
[20:55] <mdiggory> yes, if the project is managed well
[20:55] <mhwood> If it doesn't break contracts, old dependents should still work with new dependencies or the code is bad.
[20:56] <mhwood> We can't control how e.g. log4j is managed but we *do* control how the bits of DSpace are managed.
[20:56] <tdonohue> So, any counter proposals here, or agreement/disagreement with what either mdiggory or I have proposed previously? Or are we still "not necessarily on the same page"?
[20:56] <grahamtriggs1> richardrodgers: you can always edit your pom and add the dependencies to it. We could have a 'pom generation script' that asks the questions and creates the pom that you'll use combining the released pom with information it's gleaned about available modules. What we can't have is a spaghettie mess of dependencies between the 'release' and the optional modules.
[20:56] <robint> I find mdiggory proposal coherent and in some respects attractive, but there is a price in complexity and I still need to be convinced of the immediate need
[20:56] <mdiggory> grahamtriggs1: thats called an archetype... and we can make a multimodule one...
[20:57] <tdonohue> Ok, so it sounds like robint is close to a +1 for mdiggory's ideas (maybe at a +0.5)...others have thoughts here?
[20:58] <richardrodgers> grahamtriggs1: I agree that there is avoidable complexity in how we manage deps today
[20:58] <mhwood> I think there's still some support for "none of the above". I'm undecided myself.
[20:58] <robint> tdonohue: not yet :) I dont really see the need as yet
[20:58] <tdonohue> that's "undecided" for mhwood. others?
[20:59] <stuartlewis> Undecided.
[20:59] <stuartlewis> Would like to see a demo of it all working in action.
[21:00] <richardrodgers> I'm a prototype-*then*-vote kind of person
[21:00] <mhwood> Can developers all get what they need if we pull projects off the main release train one at a time?
[21:00] <mdiggory> Are we referring to the Domain Model work ?
[21:00] <stuartlewis> richardrodgers: +1
[21:00] <robint> I would be happy to see the refactoring of dspace-api continue but I'm not yet commited to moving code out to modules directory
[21:00] <mdiggory> Demoing can work, but it requires a bit of branching a prototype and actually releasing it
[21:00] <tdonohue> stuartlewis -- demo of which parts? how to do a release async? or something else?
[21:01] <stuartlewis> Yeah - an async release done for some small part, so we can see it working.
[21:01] <stuartlewis> Like Richard says, a prototype.
[21:01] <mdiggory> I've tried to keep all the actual dspace-api changes to a bare minimum of class signatures
[21:01] <PeterDietz> I'm in favor of async, unsure of implementation specifics. I think it would be wise to prune DSpace/DSpace (aka minified trunk) down to just the bare necessities (so I'm thinking just dspace-api + poms). From there you can wire in the project you do want to use (xmlui, sword, oai, xmlui, rest-api, jspui, webmvc, lni)
[21:02] <mdiggory> PeterDietz: I"m not convinced, nor have I been in the past with the proposal, that we would need to exclude source that currently in the main trunk from being there
[21:02] <tdonohue> Ok. Sounds like most are in the "undecided about async -- we'd like to see a demo/prototype first" camp.
[21:03] <richardrodgers> gotta go - interesting discussion, thanks all
[21:03] <mdiggory> ouside of wanting to take discovery and stats back into the modules workspace
[21:03] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:03] <mdiggory> PeterDietz: a minified trunk would/could just be svn/repo/dspace/trunk/dspace
[21:04] <PeterDietz> by default maven can fetch your <modules> from released maven repository, so most likely the latest available, unless you've locked down specifically to a certain version. alternatively, you could tell it to use another directory for module.
[21:04] <tdonohue> mdiggory, are you working on any sort of "prototype" of your async ideas? or willing to do so? (or is this work just happening as part of 1.8 stuff?)
[21:05] <mdiggory> its on 1.8 at the moment because I'm working locally on it via installation only
[21:05] <PeterDietz> I was thinking that minified trunk would be [dspace-source]/dspace too. Perhaps that can be the agreed baseline, then seperate dspace into modules for everything.
[21:06] <tdonohue> Per all this talk around "minified trunk". I think it's good to think about, but I'd warn that we probably should also think about ways to "package up a release" such that it can be installed *without* maven. See DS-802
[21:06] <kompewter> [ https://jira.duraspace.org/browse/DS-802 ] - [#DS-802] Create a DSpace "Installer" which doesn't require users to build DSpace using Maven and Ant - DuraSpace JIRA
[21:06] <mdiggory> PeterDietz: think about the maven-release plugin... see where it tags the releases if you were to run it individually in a [dspace-src]/dspace-xxx project
[21:06] <mdiggory> you'll immediately see that "dspace-parent" needs to go awa y for it to work
[21:07] <tdonohue> So, don't confuse "minified trunk" with "have our users install UIs via Maven" ;)
[21:07] <mdiggory> the release order would be something like dspace-api, dspace-stats, dspace-xmlui-api, dspace-discovery, ....
[21:07] * tdonohue notes we're over time here...sorry to run long again
[21:07] <mdiggory> the release tag location would be identicial to the current tags
[21:08] <mhwood> Order? That's not asynchronous.
[21:08] <mdiggory> mhwood: you stickler
[21:09] <mdiggory> but the releases would have different numbering schemes /naming
[21:09] * bojans (~Bojmen@91-118-63-172.dynamic.adsl-line.inode.at) Quit (Ping timeout: 240 seconds)
[21:09] <tdonohue> At this point, it sounds like next steps are: (1) See if mdiggory or tdonohue or others can prototype/demo some sort of async process for review. (2) Continue to brainstorm these ideas amongst ourselves or write up proposals on wiki for discussion.
[21:09] <mdiggory> One of the reasons I'm not prototyping it in a branch
[21:09] <mdiggory> but... hey maybe it would be good to try
[21:10] <tdonohue> If you have to head out -- feel free. I don't have anything else on the agenda today, but I'll stick around as long as others want to chat
[21:11] <tdonohue> (i.e. consider official meeting closed, but feel free to hang around for "unofficial" chat)
[21:11] <PeterDietz> I'll see what I can do with git filter-branch. It lets you split a folder into seperate project with own history.
[21:11] <mdiggory> I wonder if someone could distill this session... theres two/three conversations happening at any one point in the chat
[21:12] <tdonohue> So, mdiggory, do we want to set up a place where we can do some "async" testing/demos?
[21:12] * barmintor (barmintor@specdl11.cul.columbia.edu) has left #duraspace
[21:12] <tdonohue> mdiggory -- to distill. I think most are still "undecided on the benefits/usefulness of async". We need one or more of us to demostrate how it would work, etc
[21:12] <mdiggory> tdonohue: I've been tempted to explore using Githhub
[21:13] <tdonohue> continued distilling: Unresolved issues remain as well -- there were concerns voiced about "visibility of code" which I'm not sure were fully answered during the discussion, but are worth further thinking about as we go forward
[21:13] <mhwood> I've been wondering about that "get rid of dspace-parent" thing. It's always coupled with creating a new project and sounds like we're just moving things around in some namespace.
[21:13] <mdiggory> maybe PeterDietz could hold our hands through how to get individual projects there... though we need to switch the pom.xml settings to capture new git locations for source and release branching... that would be a good excercise
[21:14] <tdonohue> mdiggory -- sure, I'd be willing to try and chip in on some async demo work in github (be a good excuse for me to get more familiar with it as well)
[21:14] <mdiggory> mhwood: its mostly attempting to put it under [dspacesrc]/dspace/pom.xml instead...
[21:14] <PeterDietz> does maven ever touch svn code? (aside from performing release)?
[21:15] <tdonohue> PeterDietz -- no. just during the release processes, when it does svn tagging, etc.
[21:15] <mdiggory> no, just in release, and it should support git instead of svn
[21:15] <mdiggory> Tutorial by the good Time O'Brien http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/
[21:16] <kompewter> [ Sonatype Blog ยป Maven Tips and Tricks: Using GitHub ] - http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/
[21:16] <mdiggory> Time = tim
[21:16] <mhwood> So the parent becomes a sibling?
[21:17] * mhwood looks for a way to stuff a recording of "I'm My Own Grandpa" into IRC.
[21:17] <mdiggory> dspace-pom becomes the parent...
[21:17] <mdiggory> and its released separately
[21:18] <robint> Got to go, thanks all.
[21:18] * robint (522921b0@gateway/web/freenode/ip.82.41.33.176) has left #duraspace
[21:18] <mdiggory> so that all builds can depend on dspace-pom freely
[21:18] <mhwood> See, that's where I lose the thread. We abolish the parent and then we create a new parent.
[21:18] <mdiggory> without it being present in the distro
[21:18] <PeterDietz> Mainly it will just be dspace-minified (which is [dspace-source]/dspace).. wait now I'm confused
[21:19] <mdiggory> we liberate the parent from being released with the release
[21:19] <mdiggory> This is how many many Maven multimodule projects work
[21:19] <PeterDietz> where does dspace-api live, and how should dspace-minified live without it?.. i guess it pulls api in through pom
[21:19] <mdiggory> including Maven itself
[21:20] <PeterDietz> ok, so dspace-min is very very basic, probably no java files
[21:20] <mdiggory> depends on if you want it or not... svn co http://scm.dspace.org/svn/repo/dspace/trunk/dspace dspace
[21:20] <kompewter> [ Revision 6366: /dspace/trunk/dspace ] - http://scm.dspace.org/svn/repo/dspace/trunk/dspace
[21:20] <mdiggory> svn co http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api dspace-api
[21:20] <mhwood> Probably why I have never yet figured out how to build Cocoon 2.2 from source.
[21:20] <kompewter> [ Revision 6366: /dspace/trunk/dspace-api ] - http://scm.dspace.org/svn/repo/dspace/trunk/dspace-api
[21:20] <mdiggory> cd dspace; mvn package;
[21:21] <mdiggory> you now have dspace-api built on your release
[21:21] <PeterDietz> dspace-api has lot of java files, gets connected to dspace-min as THE primary module of dspace-min.. (maybe you can replace dspace-api with some exotic thought of mdiggory's such as dspace-dao)
[21:22] <mdiggory> exotic... I"m trying to decide if thats a compliment ;-)
[21:22] <mdiggory> but yes, spot on...
[21:22] * tdonohue thinks this discussion needs a writeup somewhere -- getting a bit confused myself on what exactly the hierarchy / SVN structure is that is being discussed
[21:23] <mhwood> +1 to that
[21:23] <mdiggory> I actually did not change any hierarchy just then... you can do it in the tags too
[21:23] <mdiggory> its works better there because the dspace-parent is actually released
[21:24] <PeterDietz> Then. People like Ohio State, who use xmlui as their primary UI, will have to have dspace-min/pom.xml have a module entry for xmlui. This fetches xmlui from maven repos
[21:24] <tdonohue> what/where is 'dspace-min' then? is it [dspace-src] or [dspace-src]/dspace/ or something else entirely?
[21:24] <mdiggory> if we had bamboo doing interim deployments of snapshots... I'd feel safer saying it about trunk
[21:25] <tdonohue> we can reconfigure bamboo --it's there as a tool for us to do with as we see fit
[21:25] <PeterDietz> [dspace-src] becomes a misnomer. It implies it contains source code.
[21:26] <mdiggory> http://scm.dspace.org/svn/repo/dspace/trunk/dspace = dspace-min = dspace-release-XXX.zip
[21:26] <kompewter> [ Revision 6366: /dspace/trunk/dspace ] - http://scm.dspace.org/svn/repo/dspace/trunk/dspace
[21:26] <PeterDietz> so I guess maybe the thinking change to [dspace-main] == dspace-min
[21:27] <mdiggory> This is not a new construct, we use it int he release distro...
[21:27] <tdonohue> so, see you are changing hierarchy terms then :) Hence, my request for a writeup, so that I could make sure I understand what exactly is changing and what is not
[21:27] <PeterDietz> dspace-min has pom entries for all the modules
[21:29] <mdiggory> Sorry...slight error on my part dspace-release is at http://scm.dspace.org/svn/repo/dspace/trunk/ but excludes dspace-* projects
[21:29] <kompewter> [ Revision 6366: /dspace/trunk ] - http://scm.dspace.org/svn/repo/dspace/trunk/
[21:29] <mdiggory> so startes with dspace-parent pom at top... which I think confuses folks
[21:30] <mhwood> That it does. Changing down to a directory that then looks back up....
[21:30] <mdiggory> if we excluded dspace-parent.pom from that release... then the user would traverse into dspace without much thought and build there
[21:30] <PeterDietz> sorry gotta run. I'll try to make some git modules to look at
[21:31] <mhwood> Well, no, then he's got a directory containing a bunch of directories, all containing pom.xml...which is *the* POM?
[21:31] <mdiggory> mhwood: trying to clear that issue up by having all build profiles be executed from http://scm.dspace.org/svn/repo/dspace/trunk/dspace and merging dspace-parent logic into it
[21:31] <kompewter> [ Revision 6366: /dspace/trunk/dspace ] - http://scm.dspace.org/svn/repo/dspace/trunk/dspace
[21:32] <mdiggory> and tdonohue thats where we should think about your profiles enabling specific modules in the build
[21:32] <PeterDietz> The "god" pom should become what current is known as [dspace-source]/dspace/pom.xml
[21:32] <PeterDietz> That can be [dspace-min]/pom.xml
[21:33] <PeterDietz> I'm probably only adding to confusion. So, see you later all.
[21:33] * KevinVdV (~KevinVdV@d54C15567.access.telenet.be) Quit (Ping timeout: 240 seconds)
[21:33] <mdiggory> god pom is more like... dspace-pom.... Jesus Christ pom is more like dspace/pom.xml
[21:33] <PeterDietz> then you run into semantics of who is the father, and who is the child
[21:33] <mdiggory> God is in heaven... Jesus comes to earth to save us
[21:33] <tdonohue> ok, starting to grasp what you mean now. Still think it might be worth a writeup though (even in JIRA), before jumping in and moving pom contents around ;)
[21:34] <mdiggory> wow cannot believe I just said that in a logged channel
[21:34] <PeterDietz> DSpace could perhaps become the prototype of a pantheon. dspace-min is zeus. webmvc can be hermes because I'm hoping that its fast
[21:35] <PeterDietz> dspace-lni can be Hades since nobody uses it
[21:35] <stuartlewis> We've got our new lightweight UI working now, and it's nice and fast :)
[21:35] <mhwood> Hmmm, titans....
[21:35] <stuartlewis> PHP MVC (CodeIgniter) sitting on top of dspace-discovery solr index. No postgress access required.
[21:35] <mdiggory> anyhow... the point is that your free to hack dspace/pom.xml while dspace-pom is strictly controlled.
[21:36] <mdiggory> stuartlewis: make my day...
[21:36] <mdiggory> show me a link
[21:36] <PeterDietz> congrats stuartlewis.. but for reals. I'm stepping away now
[21:37] <stuartlewis> No link yet - we'll demo at OR, and if people liek it, we'll move it to github or somewhere.
[21:37] <stuartlewis> It's not a DSpace UI per-se, but a themable 'collection viewer'
[21:38] <mdiggory> stuartlewis: JSON driven?
[21:38] <stuartlewis> xml from solr
[21:38] <stuartlewis> But we could use the json instead.
[21:39] <mdiggory> bah... danger will robinson... we are trying to keep that /solr url private to dspace...
[21:39] <stuartlewis> But why?
[21:39] <stuartlewis> It is a great integration point.
[21:39] <mdiggory> because its got sensitive stuff in it
[21:39] <stuartlewis> We only open it up to UI, not to the world.
[21:39] <tdonohue> stuartlewis: any plans to share?
[21:39] <mdiggory> ok ok...
[21:40] <stuartlewis> tdonohue: we'll demo at OR, and if people like it, we'll move it to github or somewhere.
[21:40] <tdonohue> share first, apologize later (kidding) ;)
[21:40] <mdiggory> want to get a proxy servlet wrapped around the solr webapp that can enforce access control filtering on it
[21:41] <stuartlewis> We've also written a small oaipmh proxy, so that the UI offers oaipmh that points harvesters back to it (proxies to dspace's oai-pmh interface)
[21:41] <mdiggory> index workflows but filter on permissions.
[21:41] <tdonohue> definitely looking forward to that demo, stuartlewis...would like to see it in action.
[21:43] <mhwood> Lots to think about, but now I must go. Thanks, all!
[21:43] * mhwood (~mhwood@adsl-99-162-50-38.dsl.ipltin.sbcglobal.net) has left #duraspace
[21:44] <stuartlewis> Screen shot of one of our collections: http://stuartlewis.com/si-nzais.jpg
[21:49] <mdiggory> Is anyone watching The Fascinator? Seems to have come together quite nicely... something to consider
[21:50] <mdiggory> http://fascinator.usq.edu.au/
[21:50] <kompewter> [ The Fascinator ] - http://fascinator.usq.edu.au/
[21:50] <stuartlewis> Will be interesting to see how it develops, now that Peter Sefton has left.
[21:50] <mdiggory> thats news to me...
[21:50] <tdonohue> me too (note: we're on a logged channel -- not sure if this is all public info or not?)
[21:50] <mdiggory> hes listed doingthe workshop at OR
[21:51] <stuartlewis> Yep - all public. Left a month or so ago.
[21:51] <stuartlewis> http://stuartlewis.com/si-nzais.jpg
[21:51] <stuartlewis> Whoops!
[21:51] <stuartlewis> I meant: http://ptsefton.com/2011/03/24/onwards.htm
[21:51] <kompewter> [ Onwards | ptsefton ] - http://ptsefton.com/2011/03/24/onwards.htm
[22:01] * sandsfish (~sandsfish@18.111.25.122) Quit (Quit: sandsfish)
[22:07] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[22:45] * grahamtriggs1 (~Graham@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: Leaving.)
[23:54] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
