Timestamps are in GMT/BST.
[1:47] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[4:07] -hubbard.freenode.net- *** Looking up your hostname...
[4:07] -hubbard.freenode.net- *** Checking Ident
[4:07] -hubbard.freenode.net- *** Found your hostname
[4:07] -hubbard.freenode.net- *** No Ident response
[4:07] [frigg VERSION]
[4:07] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:07] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:07] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[5:02] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[5:03] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[6:11] * grahamtriggs (~trig01@80.169.130.178) has joined #duraspace
[8:00] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[8:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[8:13] * ksclarke (~kevin@184.39.7.249) has joined #duraspace
[8:15] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[9:27] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[9:31] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[11:56] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[11:57] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[13:03] * grahamtriggs (~trig01@80.169.130.178) has left #duraspace
[13:15] * kstrnad (~kstrnad@HSI-KBW-109-192-160-151.hsi6.kabel-badenwuerttemberg.de) has joined #duraspace
[13:54] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[13:55] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:01] * tdonohue1 (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:01] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Disconnected by services)
[14:01] * tdonohue1 is now known as tdonohue
[14:11] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Quit: scottatm)
[14:28] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[14:30] * kstrnad (~kstrnad@HSI-KBW-109-192-160-151.hsi6.kabel-badenwuerttemberg.de) Quit (Quit: leaving)
[15:07] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:08] * mdiggory (~mdiggory@99-10-127-11.lightspeed.sndgca.sbcglobal.net) has joined #duraspace
[15:36] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:53] * robintaylor (~52292565@gateway/web/freenode/x-pnkkpdrfsturvexx) has joined #duraspace
[15:53] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[15:55] * carynn (~80c8e115@gateway/web/freenode/x-huxukvdxohecmdcp) has joined #duraspace
[15:56] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[15:57] * anj (~anj@cpc1-leed16-0-0-cust983.leed.cable.ntl.com) has joined #duraspace
[15:58] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[15:59] <tdonohue> Hi all, we'll be starting the DSpace Developers Meeting here shortly. Today is a Special Topics meeting to begin to discuss the DSpace RoadMap (1.7 & Beyond). Very general agenda was sent to dspace-devel: http://sourceforge.net/mailarchive/message.php?msg_name=4BBB9CBC.9080302%40duraspace.org
[15:59] * richardrodgers (~richardro@dhcp-18-111-9-121.dyn.mit.edu) has joined #duraspace
[16:01] <carynn> hello, all~ just an fyi... i have to head out early today. so, when i abruptly exit, it's just so i can get to my next meeting. :-D
[16:01] <tdonohue> Ok. we're at the top of the hour, so we may as well start the meeting. First off, I'm under a 'severe thunderstorm warning' right now, so if I suddenly go offline or become very quiet, it's likely that my power has gone out (but I'll cross my fingers and hope this blows over quickly)
[16:02] <tdonohue> I don't have a real agenda for today -- this is more of a brainstorming meeting to get us to all discuss upcoming RoadMap
[16:02] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:02] <tdonohue> the main thing I'd like to start with is to begin some basic planning for 1.7 -- what features do we already "have ready" or will have ready by December that could go into 1.7
[16:03] <richardrodgers> Well just from a planning point of view, I can share some stuff we are working on in a 1.7 time frame
[16:03] <tdonohue> go for it richardrodgers
[16:03] <mhwood> Personalization and crowd-sourced enhancements to content have been a hot topic today.
[16:03] <richardrodgers> http://fedora-commons.org/confluence/display/DSPACE/CGIProposal
[16:03] <richardrodgers> http://fedora-commons.org/confluence/display/DSPACE/CurationTaskProposal
[16:04] <richardrodgers> those would be the bigger ones, we have a few smaller as well
[16:04] <tdonohue> How does the CGI (context guided ingest) mesh with robintaylor's work?
[16:05] <richardrodgers> it resues some code and generalizes the approach
[16:06] <tdonohue> very cool -- those all look interesting -- would be good to get into JIRA to track for 1.7
[16:06] <tdonohue> I'll also note that I'm working on http://jira.dspace.org/jira/browse/DS-466 to be ready for 1.7
[16:06] <richardrodgers> OK will do
[16:07] <tdonohue> Is there other work out there that people feel could be ready for 1.7? All of these items mentioned are "potentials" -- obviously, we'll need to do further planning/vetting later on -- but, just want to get these ideas on table now
[16:08] <richardrodgers> on a smaller scale, we rewrote Creative Commons to:
[16:08] <robintaylor> I am working on a Sword client for Dspace. I hope to have it ready fairly soon.
[16:08] <richardrodgers> (1) use web service, so no UI lock-in
[16:09] <tdonohue> robintaylor: So, this would be to allow DSpace to send items to another location via SWORD?
[16:09] <richardrodgers> (2) express in RDFa in page, per current best practices
[16:09] * anj (~anj@cpc1-leed16-0-0-cust983.leed.cable.ntl.com) Quit (Quit: anj)
[16:09] <richardrodgers> (3) store CC info in metadata, so searchable, etc
[16:09] <robintaylor> tdonohue: yes
[16:09] <tdonohue> robintaylor: cool
[16:10] <carynn> with the cc stuff - is there a way to allow users to pick *only* a cc? i.e. as the system is now, you have to pick a cc license *and* agree to a standard license, right?
[16:10] <mhwood> I have a little gadget to return an XML document containing basic repository size statistics (how many items/collections/communities, how much storage used by bitstreams) in support of our library's "dashboard".
[16:10] <carynn> any way to de-couple?
[16:10] <richardrodgers> mhwood: those are independently configurable, if I understand your question
[16:11] <mhwood> I think that was to carynn?
[16:11] <richardrodgers> yes, sorry
[16:11] <mdiggory> hi sorry, I was distracted
[16:11] <carynn> thnx - that is something i would definitely like to implement!
[16:12] <tdonohue> mhwood: sounds very interesting. could you put in a note about it in JIRA or somewhere so we can "see in action" or look at in more detail
[16:12] <mhwood> Will do.
[16:12] <tdonohue> mdiggory: right now we're just putting things on the table for 1.7 -- discussing what we all are working on that could be potentially be ready for 1.7 in Dec
[16:13] <mhwood> It needs some more work, making it more rugged, and some more thought.
[16:13] <tdonohue> mhwood: understandable
[16:14] <tdonohue> I guess, in my mind, the easiest way to start to pull these various proposals for 1.7 features together may be to add them to JIRA (either as just a description/placeholder, or as real code, if there is real code).
[16:15] <tdonohue> I'll add a "1.7" version to Jira after this meeting -- and we can start pulling more ideas together there
[16:15] <mdiggory> Yes, I gather, that would be a good topic, also want to discuss how we work together to decide what will go in and what ordering.... Likewise, concerned about just pitching ideas here... what is the process for, as one of your points int he wiki suggested... keeping us on track to what 2.0
[16:15] <kshepherd> brb, just running from home->office
[16:16] <mdiggory> There are projects which are not "shinny" we need to see worked on to do that...
[16:16] <mdiggory> Things like Porting existing codebase in 1.x to use Service framework...
[16:17] <tdonohue> mdiggory: agreed, and understood. So, do you feel the better way at getting at those not "shiny" projects is to talk beyond 1.7 right away, and work backwards?
[16:19] <mdiggory> Well, as with any OS community there are alot of ideas, ideas being worked on in isolation/semi-isolation and challenges at integrating them into the roadmap
[16:19] <mdiggory> I've seen 3-4 ideas just in this thread that I've not seen before
[16:19] <carynn> quick question... do we generally keep a list of "desired features", then assign a release? or do we way "let's do a release" and identify features that way? just curious...
[16:19] <mdiggory> I havn't a clue how they will impact eachother or if they will take into considerationt he changes in services that went into 1.6
[16:20] <mdiggory> I'm not even sure if the developer community understands what dspace-services are, let alone how to use them
[16:20] <mhwood> I think that a number of community members [raises hand] need to further cultivate the habit of asking, "would this thing I just did be useful to others?"
[16:21] <richardrodgers> carynn: that's a tricky question! We generally work from local requirements and feed to the middle...
[16:21] <grahamtriggs> mdiggory: I'm not even convinced the even know dspace-services exists!
[16:21] <mhwood> I'm sure that "dspace services" is somewhat mysterious to *me*.
[16:22] <tdonohue> mdiggory, how can we work to make "dspace services" an understandable "thing". I'll even admit, that I'm not 100% up to speed on it
[16:22] <mdiggory> So, that is why we need a roadmap that is more than "contribution" feature related.
[16:22] <carynn> richardrogers: got it - thnx.
[16:23] <richardrodgers> mdiggory: who will implement this roadmap?
[16:23] <mhwood> So, there's some stuff we'd like to see adopted, or that we think others might like to have. And then there's a "next objective" and the trajectory to get there.
[16:23] <mdiggory> We need to choose if we all agree on t he direction and are walking together toward it, or if this is scrimmage and we all go wherever the direction greatest force is
[16:24] <mdiggory> richardrodgers: a significant group of us
[16:25] <tdonohue> right, in my mind, the roadmap needs to come from "us" (where "us" is the committers or interested/invested other developers)
[16:26] <robintaylor> mdiggory: do you mean a kind of sub-group as with DSpace 2.0 ?
[16:26] <tdonohue> So, mdiggory, you are looking for a vote/discussion of "where do we all want to go". So, you are asking if we all agree that dspace-services (and the 2.0 prototype idea) seems like a good tragectory
[16:26] <mdiggory> I will not defiine that group explicitly because that tends to cause people to stop listening
[16:27] <mdiggory> So, I'm hoping to see a mix of discussion, definitely (1) new features, (2) architectural direction
[16:28] <mdiggory> architectural direction being, what parts of DSpace need or do not need to change to progress towards that 2.0 vision
[16:29] <mdiggory> and then new features need to be taking that direction into consideration in their design and implementation
[16:29] <mdiggory> for instance... PluginManager... dspace-services is meant to basically replace significant portions of it
[16:30] <tdonohue> ok...so, here's where we get towards the "meat of the matter" (in my mind). I wonder if we all have the same vision of "2.0" or not (obviously, there was the 2.0 prototype built last year -- but is that the only vision of what 2.0 means)
[16:30] <mhwood> So we need some porting guidance, and prodding to port our plugins.
[16:31] <mdiggory> TBH tdonohue I'm hoping thats what your role is supposed to "fix" for us
[16:31] <mdiggory> :-)
[16:32] <tdonohue> mdiggory: I'll argue that it's not my role to "decide" what 2.0 is, or where we are going....I'm just helping to ensure we keep moving towards whatever it is we *all decide on*
[16:32] <tdonohue> http://wiki.dspace.org/confluence/display/DSPACE/Special+Topics#SpecialTopics-Whatis2.0%2Creally%3FHowdowegetthere%3F
[16:32] <tdonohue> That wiki link is to a question that has popped up on IRC recently frequently -- "What is 2.0? and how do we get there?"
[16:33] <mdiggory> I know I'm treading a fine line here... but I challenge that is a choice that is upto you
[16:33] <mdiggory> Yes, we all need to decide what is relevant to 2.0
[16:34] <tdonohue> I know this is potentially opening up a "can of worms" here. Do we want to dig into this discussion? what do others think?
[16:34] <mdiggory> I certainly have my own viewpoints, both practical and evangelical based upon what was successful and unsuccessful from last year
[16:34] <mhwood> Mmmm, we need input from the folks who will have to use it. There is a candidate answer on the table. Does it support their needs? It's a good design but is it the right good design?
[16:35] <mhwood> I recall that I liked as much as I understood.
[16:35] <mdiggory> I want to be careful not to start to lead a 2.0 vision discussion
[16:35] <mdiggory> Because that will take a great deal of time
[16:36] <grahamtriggs> tdonohue: that's getting awfully close to acknowledging that there may be an elephant in the room
[16:36] <tdonohue> understood. I definitely wouldn't expect us to make a final decision in the time alloted -- this is an ongoing discussion
[16:36] <mdiggory> grahamtriggs: don't you start talking about my weight again
[16:36] <tdonohue> there is an elephant in the room, and we have named him "2.0"
[16:37] <grahamtriggs> the other elephant... you know... the one in the other corner
[16:37] <tdonohue> So, a few thoughts to throw out -- feel free to latch on to them or not
[16:37] * mdiggory holds breath
[16:37] <tdonohue> (1) we're running out of 1.x numbers : 1.7, 1.8, 1.9 -- we need to go to 2.0 soon or renumber altogether
[16:38] <mhwood> The version after 1.9 is 1.10.
[16:38] <grahamtriggs> 10.12 ... *hides*
[16:38] <mhwood> The natural numbers don't "run out".
[16:38] <tdonohue> (2) there are various larger features that are often requested (ahem...versioning) which will require us to re-architect eventually
[16:38] * tdonohue stands corrected by mhwood...we'll just make a roadmap towards 1.20000 ;) (kidding)
[16:39] <grahamtriggs> Duraspace Press Release - Open Repositories 2986.... Duraspace is proud to announce the release of DSpace 1.infinity
[16:39] <mdiggory> No matter the version numbering... the natural progression is leading us to an eventual major release, and that pressure is a good thing, not a bad thing
[16:40] <tdonohue> (3) Since the creation of DuraSpace, there has been a lot of interest (not just from us -- from outside of us) in seeing whether there could be such a "thing" as DSpace on Fedora
[16:40] <richardrodgers> I think the major/minor stuff is muted by timed release
[16:40] <mdiggory> tdonohue: we have shown its a possibility
[16:40] <mdiggory> in both GSoC and in the Funded development
[16:40] <tdonohue> (4) There have also been many questions recently about "what happened to the 2.0 work from last year" -- or at least, I've been hearing them
[16:41] <richardrodgers> For example, which Ubuntu recently had a major Linux kernel upgrade?
[16:41] <mhwood> DSpace on Fedora always sounds like a Camaro with a Mustang welded on top. What's it do?
[16:41] <mdiggory> @mire is still vested in the 2.0 Data Model work.
[16:41] <tdonohue> mhwood: very good question :)
[16:41] <grahamtriggs> Aha... elephant is standing behind door number 3....
[16:42] <PeterDietz> I'm +1 on capabilities of being able to add a feature without having to hack apart the core
[16:43] <mdiggory> The challenge is that the community got very quiet after funding stopped and time to continue working on 2.0 collaboratively ceased to be available
[16:44] <grahamtriggs> It's fair to say that the majority of questions I received at Open Repositories 2009 (although by no means is it a representative sample of the communtiy) was around the possibility / likelihood of DSpace being an 'application of' Fedora
[16:44] <tdonohue> grahamtriggs: And, I'd agree...that's what I normally hear described as "DSpace on Fedora" -- It's still DSpace, it just happens to be running as a web application on the Fedora data model
[16:45] <mdiggory> And the predominant workt hat went into 2.0 Storage Services was funded by JISC to CARET to focus not on Fedora alone, but also JCR and other CMS
[16:45] <mdiggory> So the scope was not just Fedora
[16:46] <robintaylor> Any chance of more funding from somewhere to fund 'migration to DSpace 2.0' ?
[16:46] <mdiggory> And we need to be very careful here, because Fedora is not a be-all end-all target, it is moving and evolving at the same time we are as both a codebase and a community
[16:46] <grahamtriggs> I'm all for "integrating" with other systems - but integrating with a CMS isn't the same thing as "DSpace running on top of the CMS" or vice versa
[16:46] <mdiggory> My recent converstations with Chris Wilper centered around their efforts to make Fedora "OSGi friendly"
[16:47] <tdonohue> robintaylor: I think there would be the possibility of funding for that type of migration. There's also potential initiatives right now that could help with major migrations (e.g. http://jira.dspace.org/jira/browse/DS-466)
[16:47] <mhwood> I wonder if we shouldn't look at the existing "2.0" as a very thorough proof-of-concept, and stress to the community that we are incorporating that work over time.
[16:47] <mdiggory> Which really boils down to Fedora adopting SpringDM
[16:47] <mdiggory> And Fedora reducing reliance on strict Interfaces for its API
[16:48] <tdonohue> mhwood: I like that idea.
[16:48] <mdiggory> Which is ultimately pushing Fedora towards the same traectory as dspace-services is dragging DSpace
[16:49] <mhwood> We can call it "DSpace II" and let "2.0" (or whatever scheme we're using then) be the point at which we burn the bridges and make the first incompatible architectural changes.
[16:49] <tdonohue> So, in general, do we all feel that the existing 2.0 work is best to strive towards (while also investigating whether there could be future "overlaps" with the trajectory of Fedora)? feel free to respond +1/0/-1 (though this isn't an official vote, and I won't hold you to it)
[16:50] <mdiggory> I am concerned worrying about numbers distracts us from the actual task/work/direction
[16:50] <mhwood> We're already using some of that work. We need to promote the new capabilities that that gives us, and sequence some more.
[16:50] <mdiggory> tdonohue: +1 it is obvious
[16:51] <mdiggory> there are many many levels that overlap occurs at
[16:51] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[16:51] <PeterDietz> +1 from what I understand
[16:51] <keithg> +1
[16:51] <mhwood> Since there has been no mention of alternative models, I think you are right about the rough consensus on "2.0"
[16:51] <robintaylor> +1 albeit from a position of ignorance
[16:51] <richardrodgers> 0 too vague for me to vote
[16:52] <mdiggory> I think that we are just voting on the adding of that to the list as an important roadmap topic of discussion
[16:52] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:52] <tdonohue> richardrodgers: point taken. what can help "solidify" this more? A more official proposal on how to begin moving towards the 2.0 work?
[16:53] <richardrodgers> ok - I certainly feel it is important to discuss
[16:53] <mhwood> Well, what are some portions could we schedule into 1.7?
[16:54] <mhwood> Maybe we need a list of what's in "2.0" and what's been adopted already.
[16:54] <mdiggory> mhwood: continued migration of Managers to Services via dspace-services
[16:54] <mdiggory> And thinking about the trajectories.... that means more embracing Spring
[16:55] <mhwood> Time to resume reading that Spring book.
[16:55] <mdiggory> and less creating our own home cooked configuration file formats, loaders etc
[16:55] <richardrodgers> tdonohue: yes - since th e2.0 prototype contains many disparate things
[16:55] <mhwood> Ah, there's something I'd like to see in future versions: reevaluation and possible redesign of the whole ball of configuration files.
[16:56] <mdiggory> I've prototype the first move in this direction by both porting dspace-services ConfigurationService to use dspace.cfg, EventService to replace UsageEvents and prototyped a SearchService within DSpace Discovery
[16:57] <tdonohue> mdiggory: so what of that is logical for moving into 1.7 potentially?
[16:57] <mdiggory> let me find the slide again....
[16:57] <tdonohue> and I'd warn that whatever "services" or 2.0 stuff we want to move into 1.7, we should begin planning/implementing it *now*, so that those of us who aren't as familiar with the 2.0 work can get familiar with it as we work on 1.7 together
[16:58] <mhwood> Don't forget documenting.
[16:58] <robintaylor> Off at slight tangent before the meeting ends - can we rationalise what is distributed in the source distribution ? Will we have a source distribution ?
[16:58] <tdonohue> mhwood: definitely..."documenting" as well
[16:58] <mdiggory> http://www.slideshare.net/mdiggory/dsug09-services-2255693
[16:59] <richardrodgers> can we also get a quick GSOC update?
[16:59] <mhwood> In some way, there *has to be* a source distribution, or it isn't an OSS project anymore and nobody can work on it.
[16:59] <tdonohue> GSOC update: last I checked, we only have 4 applications in (from 3 students). One other student was asking some questions in #dspace today. Deadline is Fri.
[17:00] <richardrodgers> thanks tdonohue
[17:00] <robintaylor> mhwood: I think I agree but at the moment some modules are in and some aren't
[17:00] <mdiggory> mhwood: thats not exactly true... but
[17:01] <mdiggory> Allt he source is available and can be checked otu and built
[17:01] <mhwood> Yes, I keep meaning to ask what-all I have to pull down now in order to have *everything*. Or even to know what "everything" is.
[17:01] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[17:01] <mdiggory> well, you want to build ant, maven, lucene and the postgres jdbc driver source as well?
[17:02] <mdiggory> where do you define the boundary
[17:02] <mdiggory> why do you define a boundary
[17:02] <mhwood> One of the downsides of having Maven magically pull in dependencies is not knowing so well what is in your project.
[17:02] <tdonohue> Ok. we're at time here. I know we haven't really decided anything here -- but, I still feel it's worthwhile to get this all out on the table. To move forward, I'd like to recommend that mdiggory lead a proposal for what to add to 1.7 (from 2.0), assuming mdiggory's ok with that?
[17:02] <mhwood> Well, I run Gentoo Linux, so I already build all of those. Haven't read them...yet.
[17:03] <mdiggory> I contest that, working with maven it is very clear what I am getting in my project
[17:03] <mdiggory> and I can genrate dependency reports and make decision about what will or will not be present
[17:03] <mhwood> P
[17:04] <mhwood> Sorry, I chose my words poorly. "knowing" what is inside it, not knowing which components I am using.
[17:04] <grahamtriggs> mhwood: that's why you should get maven to generate a project site that exposes a lot of the information in a more digestable way
[17:04] <mhwood> Yes, I need to get that released.
[17:05] * tdonohue the meeting is closed, if you need to head out, do so -- but I don't want to interrupt ongoing discussion
[17:06] <richardrodgers> thanks everyone, bye
[17:06] <mdiggory> tdonohue: when we say "things from 2.0" that should be in 1.7... its things that have not necessarily have been implemented yet in some (possibly many) cases
[17:06] * stuartlewis forgot about our clocks going back. Whoops! Just missed the meeting :(
[17:06] * richardrodgers (~richardro@dhcp-18-111-9-121.dyn.mit.edu) Quit (Quit: richardrodgers)
[17:07] <tdonohue> mdiggory: so, I'd say include that in the proposal. I'm more looking for guidance from the 2.0 team on what are logical steps to make in 1.7
[17:07] <mdiggory> We ahve interfaces, but not implementations... and specifically not portings of legacy 1.x work to use services
[17:07] <grahamtriggs> mhwood's point about pulling down 'everything' shouldn't just be about the compiled depedencies (commons-*, lucene, etc.)... but also all the dspace maintained source that goes into a deployment - because that boundary has been redrawn between 1.5 and 1.6
[17:07] <mdiggory> I think I want to volunteer grahamtriggs to also be participating in that.
[17:08] <tdonohue> what I need to see from the 2.0 team is what you all would recommend to add to 1.7 (whether it is built or not), and then we can work from that list to start to assign tasks to people, or reschedule for 1.8 as needed.
[17:08] <mhwood> That's mostly what I'm talking about. I'm willing to let e.g. log4j be a black box, right now, but if I'm hacking on DSpace then I want all of DSpace, not just the bits that *have* to be rebuilt. I need to understand some of the other bits.
[17:08] <tdonohue> yea...and I'm including grahamtriggs on that, in saying the "2.0 team"
[17:09] <grahamtriggs> I'll barter allowing a component to be backported for the release to be called '10.12' :)
[17:09] <keithg> I'd like to at least know where to find the source for dependencies that are pulled down automatically by Maven - and I don't know enough about Maven yet to always be able to do that
[17:09] <mdiggory> grahamtriggs: mhwood the point of drawing that division is architectural... to get the painters and decorators from rewiring the electrical outlets and removing important structural timbers by knocking out walls
[17:10] <mdiggory> we need to stop willy-nilly hackery in the core of the codebase
[17:10] <grahamtriggs> if the painters and decorators don't even know the electrical outlets are there, they'll paper over them and drill screws through the wiring!
[17:11] <mdiggory> yes, you can get the code for dspace-services, build it into dspace 1.6, even change it. But it just shouldn't be something we give as a power to the enduser.
[17:12] <mdiggory> or... I mean
[17:12] <mdiggory> only if they are "ready" to use it
[17:12] <tdonohue> mdiggory -- I think we keep running into the same problems here -- not everyone *knows* all this as well as you do ;) we all need a bit of guidance now and then (like keithg's common question of "where is all the source")
[17:12] <mhwood> Well, I was talking about developers, not end users.
[17:12] <PeterDietz> agree to a degree. sometimes I find myself digging into code I'll not touch, but somewhat for information as to know what some objects toString will be.
[17:12] <mhwood> tdonohue: hear, hear
[17:12] <tdonohue> keithg: fyi: the source that is not in trunk is under 'modules': http://scm.dspace.org/svn/repo/modules/
[17:13] <tdonohue> keithg: but, figuring out which modules are actually included in out-of-the-box DSpace is another issue -- and that requires looking at Maven pom.xml files right now
[17:13] <grahamtriggs> I'm sorry, but obscurity is not an option... it's absolutely vital to the health of open source to get as many eyes on as much of the code as possible.
[17:13] <mdiggory> tdonohue: it really took a whole year for me to grok what Aaron bestowed upon us to the degree that I could maintain it. So I understand everyone else not even fathoming it.
[17:14] <mhwood> Hmmm, maybe a dab of XSL can extract readable lists from the POMs.
[17:14] <mdiggory> grahamtriggs: no argument there
[17:14] <tdonohue> mdiggory: exactly. So, this is why we (the committers) need more guidance from the 2.0 team -- we just don't understand all this "vision" yet
[17:15] <tdonohue> I'm hoping that mdiggory and grahamtriggs can help *me* to even "grok" it all, so that I can start to help everyone else out :)
[17:15] <mdiggory> grahamtriggs: I'm just arguing about the conduit of delivery and modularity of the source.
[17:15] <grahamtriggs> yes, that code shouldn't be changed lightly... and as 'custodians', it's our duty to ensure that changes aren't being made to the code that everyone relies on without due care and attention...
[17:16] <mdiggory> tdonohue: I would be glad to talk about it with you guys.
[17:16] <PeterDietz> sounds like mdiggory can give a webcast of "what is services"
[17:17] <mhwood> Well, that's what the committers are for. We're supposed to look at contributions and ensure that they should go in as-is, or ask for changes, right?
[17:17] <tdonohue> PeterDietz: Interesting idea....hmmm...
[17:17] <mdiggory> mhwood: The tools use the poms to generate maps, you don't need to do things at that low a level
[17:17] <tdonohue> mhwood: yes, that's it in a nutshell
[17:18] <mdiggory> gulp... ok
[17:18] <grahamtriggs> mdiggory: do you mean in terms of upholding the sanctity of dspace-services, or it's location in svn?
[17:18] <mdiggory> it scares me when we mix religion and software engineering...
[17:19] <mdiggory> but I guess I opened that can of wroms
[17:19] <tdonohue> mdiggory: I'm going to email you to set something up (not necessarily a webcast...yet)
[17:20] <mdiggory> grahamtriggs: yes, its sanctity, which is promoted at the moment by its separateness from trunk.
[17:21] <mdiggory> but we all need to realize we (committers) all have access and a right to manage this codebase
[17:22] <tdonohue> mdiggory: noting that this comes back to the same issue --- this is undocumented and "unrealized" by many -- again, you know it better than us ;)
[17:24] <mdiggory> Not to butcher metaphors but.... I liken it to the farmer who continues to hold fast to not selling his land while an entire city is growing up around him, eventually you have to look up from the fields of old "trunk" and realize the community has grown up around you and you are only looking at just part of the whole.
[17:24] <mhwood> I don't see why e.g. Services is protected by being just to the left of the trunk.
[17:24] <mdiggory> because trunk is too limiting
[17:24] <mhwood> That may be the right place for it, but is protection the reason?
[17:25] <mdiggory> trunk is a small little place where everything has to grow in lockstep
[17:26] <mhwood> So it isn't really to protect it from damage, but to protect it from scheduling.
[17:26] <mdiggory> we keep chopping down the trees because we want them to stay the same hight as the corn
[17:26] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[17:27] <mdiggory> sorry, your probably starting to wonder what I'm drinking..
[17:27] <mhwood> Coffee, wasn't it? :-)
[17:27] <tdonohue> I'd still encourage us to document how we are using SVN better (where things are, etc). We cannot expect new committers to have to dig around all areas of the SVN to try and find where everything is :)
[17:27] <mhwood> Yes, I think that's my point. And not just the newest ones.
[17:28] <mdiggory> I'm trying... I'm trying.... the new wiki is a godsend
[17:28] <tdonohue> mhwood: yea, agreed...not just the new committers -- but, actually any committer
[17:28] <mdiggory> Need more organization around the pages, more structuring....
[17:29] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/Modules
[17:29] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/DSpace+Discovery
[17:29] <tdonohue> Yea, I saw you created that Modules area in the new wiki
[17:29] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/DSpace+Services+Framework
[17:29] <mdiggory> Need farmers...
[17:29] <keithg> tdonohue: I did get a nice e-mail message explaining where different pieces are located, which was helpful. It just hadn't sunk in yet.
[17:29] <mdiggory> Not just a gardner....
[17:30] <mhwood> Or foresters
[17:30] <mdiggory> apparently ;-)
[17:30] <mhwood> Will bookmark those and read but I need to go soon.
[17:30] <mhwood> Thanks!
[17:30] <tdonohue> understood -- now lets link this off of the main Wiki area somewhere, and advertise it to dspace-devel, to help find those farmers/foresters
[17:31] <robintaylor> Metaphor overdose. Time to log-off, bye for now.
[17:31] <mdiggory> I imagine great discussions about how to organize the various resources were have here....
[17:31] <tdonohue> bye mhwood and robintaylor
[17:31] <mdiggory> bye
[17:31] <grahamtriggs> but you can say it also comes down to what's important - is it more important to establish a new area for modules, or to start splitting up the projects we have into smaller artifacts?
[17:31] * robintaylor (~52292565@gateway/web/freenode/x-pnkkpdrfsturvexx) Quit (Quit: Page closed)
[17:32] <mdiggory> grahamtriggs: don;t the two go hand in hand?
[17:32] <mdiggory> I feel like I've been making the argument for years now
[17:33] <grahamtriggs> no, not at all. ultimately, they are both required, but that doesn't mean they both have to happen together
[17:33] <mdiggory> trunk/dspace is much different than dspace/trunk
[17:34] <tdonohue> mdiggory: FYI, I linked your Modules work off of here for now http://www.fedora-commons.org/confluence/display/DSPACE/CommitterInfo (for lack of a better place -- we can always move it to a more logical place later)
[17:35] <mdiggory> tdonohue: I started modules and realized it overlapped with ...
[17:35] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/Extensions+and+Addons+Work
[17:35] <mdiggory> and
[17:35] <mdiggory> http://fedora-commons.org/confluence/display/DSPACE/Contributed+Software
[17:35] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:35] * carynn (~80c8e115@gateway/web/freenode/x-huxukvdxohecmdcp) Quit (Quit: Page closed)
[17:36] <mdiggory> and I stopped forward direction on creating the page while considering things like "labels" and "children" as a means to organize the information there
[17:37] <mdiggory> Confluence is really powerful in this area... I think we want to try to take advantage of that in our top level pages that aggregate info
[17:37] <tdonohue> mdiggory, I think those other two are a bit outdated right now -- and were only put up because there was *no* place to put this stuff. I think your "Modules" area should concentrate specifically on what is in SVN -- everything else that is not in SVN can go in one of those other areas
[17:38] <mdiggory> which means maybe coming up with some guidelines on their usage
[17:38] <tdonohue> well, if you keep your Modules linked off of a developer area, and keep it developer-focused, I think it will be obvious
[17:38] <mdiggory> I'm thinking that we need to bring them together in a way that can facilitate an "incubation" workflow
[17:39] <mdiggory> It really pains me to see patches and source in zip archives attached to wiki pages
[17:39] <tdonohue> Not in all cases...some could be candidates for incubation -- but some are just parallel interesting projects which will never be added into DSpace (e.g. BibApp is listed there)
[17:40] <mdiggory> Yes there will certainly be those cases
[17:40] <tdonohue> mdiggory: agreed -- it is painful to see that, but that was the model for so long -- and many of these were created a while back
[17:40] <mdiggory> I speak more of things like... http://fedora-commons.org/confluence/display/DSPACE/DSpace+SIP+Toolkit
[17:40] <tdonohue> essentially, I think the goal should be to move them to an "incubation" page once they've been moved into our SVN. Until then, they remain "unsupported"
[17:40] <mdiggory> Which really wasn't so long ago
[17:41] <mdiggory> YES!
[17:41] <mdiggory> I'm just hoping for some buyin.... thats all
[17:42] <tdonohue> so, really, it's three pages: (1) Modules = fully supported, in SVN, (2) Incubator = not really supported yet, but in SVN, (3) External Projects of interest = not supported, not in SVN
[17:42] <mdiggory> if the path is defined... the community will walk in it won't they?
[17:42] <tdonohue> likely..if we make it clear enough...we need to make it clear though
[17:42] <mdiggory> that seems a good start
[17:43] <tdonohue> yea...so, I'd go with that 3 page route for now...we can tweak later as needed, obviously
[17:44] <mdiggory> I just am concerned that when new community members that come to http://fedora-commons.org/confluence/display/DSPACE/Extensions+and+Addons+Work are mistakenly thinking this is everything...
[17:45] <mdiggory> some of this stuff is just external projects, some code, some rather defunct
[17:46] <tdonohue> we can reorganize all that, once we have the other pages set up. That "Extensions" page was an effort by Val to just get together links to common addons/extensions -- it's now out of date, and likely needs major rework anyways
[17:48] <PeterDietz> Perhaps each module should have instructions. Think of them being things to add to your dspace. Almost like buying/installing an app from marketplace on a mobile device. They have the info, and maybe a screenshot of the main features.
[17:48] <mdiggory> I commend the effort.... but want to promote more unification and less boundaries between Community outreach and User/Devel when it comes to generating a web presence.
[17:49] <tdonohue> mdiggory: understood -- as do we. Right now, what you are seeing are just artifacts of past efforts to better promote community work. Now that we are in Confluence, we can start to rethink how this was done in the past, and do the cleanup/reorganization necessary
[17:50] <mdiggory> PeterDietz: I'd like to get there as well... the move to Confluence allows us to organize this in a collaborative manner. If it were maintained in maven sites in the svn, those creating such content would have to be commiters = bottleneck
[17:50] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[17:50] <tdonohue> frankly -- i'm hoping we scrap the entire Wiki homepage structure, and rethink that -- there's much more to work with now in Confluence
[17:50] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:51] <mdiggory> I'm thinking of... 1.) recommending that maven site be used to generate javadoc and reports of interest, but that content around using and understanding a module be based in a wiki page
[17:52] <mdiggory> That we look to projects such at the Atlassian plugins community to derive what those sub-sites should contain
[17:53] <mdiggory> tdonohue: how true...
[18:02] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[18:02] <tdonohue> ok...i'm heading out of here now...bye all
[18:02] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:18] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[18:26] * ksclarke (~kevin@184.39.7.249) Quit (Quit: Leaving.)
[19:45] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Quit: scottatm)
[19:46] * mdiggory (~mdiggory@99-10-127-11.lightspeed.sndgca.sbcglobal.net) has left #duraspace
[19:48] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[20:00] * ksclarke (~kevin@184.39.7.249) has joined #duraspace
[20:01] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[20:08] * stuartlewis (~stuartlew@121.98.157.79) Quit (Quit: stuartlewis)
[20:12] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[20:29] * bradmc (~bradmc@host215.72.248.50.conversent.net) has joined #duraspace
[20:40] * stuartlewis (~stuartlew@121.98.157.79) has joined #duraspace
[22:18] * bradmc (~bradmc@host215.72.248.50.conversent.net) Quit (Quit: bradmc)
[22:25] * bill168 (~ca41f503@gateway/web/freenode/x-zkkmiieanliugayo) has joined #duraspace
[22:53] * bill168 (~ca41f503@gateway/web/freenode/x-zkkmiieanliugayo) Quit (Ping timeout: 248 seconds)
[23:08] * ksclarke (~kevin@184.39.7.249) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.