Transcript of July 22: [16:00] <rrodgers> Hey all - is this the venue & time for weekly DSpace committers mtg (or it's successor entity)? [16:00] <bradmc> Yes, it is. [16:01] <bradmc> We'll start in a few minutes as people flow in. Topics of interest? [16:01] <rrodgers> Usual suspects - GSOC, 1.6 [16:01] <stuartlewis> Code licence - probably a quick one. Are we still legally the DS Foundation, or are we now 'Duraspace'? [16:03] <stuartlewis> Gothenburg conference - would be good to know who's going, and what they are planning on talking about. [16:04] * jat_ysu (n=jeffr...@maag127.maag.ysu.edu) has joined #duraspace [16:04] <stuartlewis> jat_ysu: Hi Jeff. We're just compiling a list of things to talk about today. Is there anything we need to talk about regarding documentation? [16:05] <jat_ysu> Just to remind folks to send me an email if they've updated something major.... [16:05] <jat_ysu> is Jira configured/able to do anything regarding documentation alerts? [16:05] <mhwood> Is that noted on the "how to contribute" pages? [16:06] <jat_ysu> I'm looking--nothing explicit regarding documentation. [16:07] <jat_ysu> And I' [16:07] <mdiggory> Hello, just getting off the phone. Sorry if I'm late [16:07] <stuartlewis> The wiki is another thing to ask about - its configuration seems to have changed recently. It requires the index.php (didn't used to), and file uploads no longer work (The upload directory (public) is not writable by the webserver.) [16:07] <jat_ysu> I'll give a brief update of what's been done in documentation and what I'm doing now to get the house in order. [16:07] <bradmc> Just getting started. Shall we do the 1.6 update, then GSOC, then rest? [16:07] <stuartlewis> With the wiki - the google search box has also dissapeared [16:08] <stuartlewis> OK - shall I start with 1.6? [16:08] <mdiggory> I hope this is not going to precipitate into the a situtatin like the migration from moinmoin to wikimedia [16:08] <bradmc> Go ahead stuart. [16:09] <stuartlewis> 1.6 batch maetadata editing - now commited (+jspui), and Kim Shepherd has kindly volunteered to work on the xmlui. [16:09] <stuartlewis> It needs a good amount of testing, because it could be disaterous if it went wrong! :) [16:09] <stuartlewis> Stats: Mark W / mark D: Any update? [16:09] <mdiggory> why the sad face? [16:10] <rrodgers> ha ha [16:10] <stuartlewis> (Did your client interpret D followed by a : into a sad face?) [16:10] <mdiggory> apparently [16:11] <stuartlewis> Stats: Mark W / Mark Diggory - Any update? [16:11] <stuartlewis> :) [16:11] <mhwood> Not here, it just looks like a screaming face on its side. [16:11] <mdiggory> Per statistics... I am still hot on the trail of working on UsageEvent (DSpaceServices) improvements [16:12] <mdiggory> This may be an important topic to discuss around 1.6 and what we want to include into it. [16:12] <mdiggory> There are two paths that we can go down with 1.6... [16:13] <mdiggory> 1.) minimal changes... use what exists in DSpace 1.6 without introducing a richer DSpace 2.0 Services capability [16:14] <mdiggory> 2.) introduce DSpace 2.0 Kernel and Services such that they can be used within DSpace 1.6 [16:14] <mdiggory> This basically would allow use of the RequestService, SessionService, CachingService and EventService in DSpace 1.6 [16:15] <mdiggory> EventService would replace UsageEvent entirely [16:15] <mhwood> That sounds like Big Changes. How many other bits would that touch. [16:15] <mdiggory> Well, it is and it is not [16:16] <jat_ysu> Would #2 provide better migration 'control' when a site goes from 1.6. -> 2.0 (That is, less "bumps in the road")? [16:16] <mdiggory> It would be (1) an example of maintaining a project "dspace-services" in the modules svn space that would be released separately and depended upon in dspace 1.6 [16:16] <mdiggory> which will be the relase model for dspace 2.0 [16:17] <mdiggory> jat_ysu: it provides a "stepping stone" for getting dspace users/developers used working with dspace 2.0 services [16:18] <mdiggory> and would assist in directing a migration path over several iterations for the dspace 1.x track [16:18] <mdiggory> IMO, there would/should be dspace 1.7 etc as features using teh dspace-services strategy are migrated and evolve [16:19] <rrodgers> I'd favor a development branch of 1.6 to demonstrate that these changes would not be destabilizing [16:19] <stuartlewis> How much effort will this take to get integrated, and for us all to learn? If it better to put our energies into this, or better to keep 1.6 simple in the sense of no major architectural changes (and release it a bit quicker), and then devote all our effort to 2.0? [16:19] <mdiggory> rrodgers: that is a understandable request [16:19] <jat_ysu> Yes, I agree....anything that gets us closer to modularity is no-brainer. [16:19] <mhwood> There will be some confusion over the changing role of dspace/modules, which IIRC was presented as a place for one's local mod.s. We'd need good communication on this point. [16:20] <mdiggory> stuartlewis: the challenge is that pushes off community involvement in 2.0 into the future (which keeps happening) [16:20] <bradmc> I hate to add to the number soup, but what about 1.5.3 vs 1.6.0 for the cocoon bug. [16:20] <mdiggory> and does not get the community involved in the direction of the project. It effecively bifurcates the community on 1.x and 2.x groups [16:21] <mdiggory> bradmc: a 1.5.3 should be a simple release [16:22] <mhwood> But we already have that 1.x/2.x split -- we'd just be taking a little longer to begin the healing. :-/ [16:22] <mdiggory> I don't think 1.5.3 would require major testathon initiatives or the like [16:23] <mdiggory> My problem is that the longer you take to begin that healing, the worse the scar will be [16:23] <mdiggory> meaning, the more you mix into 1.6, the harder it will be to untangle it later [16:23] <stuartlewis> Mark - how long do you think it would take to get a prototype 1.6+services brach up for us to see? And, if we didn't go down this route, would dspace solr stats still be a possibility? [16:24] <mdiggory> better to begin using best (bettter) practices now [16:24] <stuartlewis> mhwood: What is the state of the stats comparison work? We have @mire solr stats, what else is out there? [16:24] <mdiggory> well, Larry Stones uncovered an issue that I was suprised we missed in Usage Event [16:24] <rrodgers> hard to fix? [16:24] <mhwood> I agree that if something from 2.x fits naturally into 1.x and has immediate benefits then there's little reason not to port it. [16:25] <mdiggory> I feel the "Services" give us a better model than the custom UI coding that will be required for the preexisting reporting we do using solr stats [16:26] <mhwood> Stats: hardly anybody wants to talk about it. I will get a note out today asking for some discussion. We've had good ideas from developers but no user input. [16:26] <mdiggory> rrodgers: its anothe thing that the Services fix just by their design [16:27] <stuartlewis> mhwood: Maybe we could ask the global outreach committe if they could aks their users? Would be good for us to try and work with them more (the global outreach committee that is) [16:27] <rrodgers> Maybe then pull stats from 1.6 and plan a 1.7 with DS2 services? [16:27] <mdiggory> DSpace 2.0 Service Manager / Kernel gives a request container that is present throughout the request lifecycle in the webapplication, even caching resides within it [16:27] <mhwood> Anything that will get people to talk about what "improved statistical support" actually means. [16:28] <stuartlewis> 1.7 wouldn't come until mid 2010, how far back would that push 2.0? Don't we need to get onto 2.0 a.s.a.p.? [16:28] <mhwood> I doubt that *everybody* will rush to 2.0 no matter how good it is. 1.7 might come out *after* 2.0. [16:28] <mdiggory> Ok, our window for relase of 1.6 is (stuartlewis correct me if I;m wrong) to have an rc out by DSUG [16:29] <mdiggory> that is about 3 months away [16:29] <bradmc> 2 months better estimate ;) [16:29] <mdiggory> ok, still a good window [16:30] <stuartlewis> Yes - that would be great - then we can have a live testathon sort of thing via livecds at the DSUG, and really try to promote it (Steve Jobs keynote style! :) [16:30] <mdiggory> I propose 1.7 as yet another stepping stone of 2.0 functionality entering into DSpace... [16:30] <mdiggory> but that is speculative... [16:30] <mdiggory> I should have been more careful about presenting it as an idea without clarifying [16:30] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer)) [16:31] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace [16:31] <mdiggory> I guess I wonder how we would use feedback from the user community on statistics when its rather obvious what is wanted [16:32] <mhwood> I can see folk asking, "what's up with all these versions?" From 1.5 to 2.0 we have big changes in the data model *and* big changes in the organization and operation of the code, so maybe that would help make sense of it for some. [16:32] <stuartlewis> Regarding stats - my gut feeling is that they want something, anything, just something that looks nice, wrte reports, and give download numbers on item spash pages. [16:32] <mhwood> Is it obvious what is wanted? What is wanted? [16:32] <mdiggory> what stuartlewis just said [16:32] <mdiggory> this is what @mire wants to contribute as well [16:33] <mdiggory> we agree on including Community, Collecio, Item and Bitstream, Author and Subject statistics [16:33] <jat_ysu> I have to ask--is it possible for users to use WebFocus or Crystal reports and grab data somewhere? Could DSpace not accommodate that and nullify the need to write something for the end user? [16:33] <mdiggory> Views adn Downloads [16:34] <mdiggory> jat_ysu: this is a feature of the @mire Print Reporting modules, you can export to excel or other formats [16:34] <mhwood> I would very much like to see a way to expose data for Some Other Package to do the heavy lifting. [16:34] * bradmc has to step away in a few minutes. No reason to stop though. [16:35] <bradmc> stuartlewis: I'll get an answer on that license question [16:35] <stuartlewis> mdiggory: How easy would it be for you to get a demo going of @mire stats for people to try out? We give them 7 days for comments, then work from there? [16:35] <mdiggory> mhwood: I agree, with teh solr engine, you can query it using the REST services and do what you want with the output [16:35] <stuartlewis> bradmc: Thanks [16:36] <bradmc> stuartlewis: MIT tripped over some sysadmin work on the wiki (it was actually down). I'll ticket those remaining issues. [16:36] <mdiggory> I think I need to talk with Ben about that before giving an extimate on the UI [16:36] <mhwood> OK, I'll summarize the discussion here and ask, "is that what you want?" [16:36] <stuartlewis> mhwood: Thanks - sounds great :) [16:37] <stuartlewis> rrodgers: How are things with embargoes? [16:38] <rrodgers> Good - I've been working with Larry Stone and we now have an API and Harvard's implementation [16:38] <rrodgers> What is needed is a 'generic reference implementation' - it will differ a bit from Harvard's [16:38] <stuartlewis> So a decision has been made as to the chosen solution? That's good. Do you have a rough timescale for getting it committed? [16:39] <stuartlewis> Sorry - typed that too soon. [16:39] <mdiggory> rrodgers: is it Item level Embargo or Bitstream level Embargo? [16:39] <rrodgers> Item -level [16:39] <stuartlewis> Do you / MIT have the effort to do the ref implementation, or are you looking for volunteers? [16:39] <stuartlewis> Could it be extended for bitstream level? [16:39] <rrodgers> Volunteers welcome [16:39] <rrodgers> Not really [16:39] <mdiggory> we implemented Item level embargo for NESCent, that source is publically available [16:40] <rrodgers> Yes and this represents a more general solution of the same thing [16:41] <rrodgers> I'll put it up on the wiki - and folks can have a poke at it [16:42] <mdiggory> sounds good, my hope is to assure there is compatibility. [16:43] <rrodgers> Indeed, this should make all the Item-level custom solutions much easier to maintain, since they become plugins of well-defined interfaces [16:43] <stuartlewis> So, do we reckon we can have stats & embargoes readin the next 8 weeks? [16:43] <stuartlewis> s/readin/ready [16:43] <rrodgers> I'd say yes for embargo - even without help [16:44] <stuartlewis> Great stuff :) [16:44] <mdiggory> I would tentatively say yes for stats, as long as theres agreement [16:44] <mdiggory> agreement on strategy that is [16:44] <stuartlewis> mdiggory: It is probably a case of silent agreent with stats - unless anyone shouts loudly against your solution, I'd take it as agreement. [16:45] <mhwood> I think at this point we may have to (not that I think that would be bad). [16:46] <rrodgers> stuartlewis, I also think our Batch-edit stuff is nearly ready (ItemUpdate) [16:46] <stuartlewis> OK - so are we done with 1.6 update? (thanks for the very positive progress updates) [16:47] <stuartlewis> rrodgers: great - it sounds another useful tool. [16:48] <kshepherd> sorry i'm late. *scrolls up* [16:48] <mdiggory> some of my concernes have more to do with "integration" we have a lot of cooks in the kitchen, how do we coordinate the workflow [16:48] <mdiggory> how many different "branches" will be running on 1.6 and how will they come together in the end [16:48] <mhwood> Modularity! :-) [16:49] <mdiggory> we love modularity [16:49] <rrodgers> I've only heard 2 - mainline and DS2 branch [16:49] <mdiggory> but I suspect there will be dspace-api, jspi, and xmlui changes that need special attention from all in the group [16:50] <mdiggory> rrodgers: oh... theres more ;-) [16:50] <mhwood> I suppose I imagine that the release coordinator will watch those branches and decide what is ready to merge. [16:50] <stuartlewis> What is your main concern? Conflicting api changes for embargoes and stats? [16:50] <rrodgers> No content API changes for embargo [16:50] <mdiggory> and whatever else is in development on outside channels [16:51] <rrodgers> No DB-schema changes either, for that matter [16:51] <mdiggory> rrodgers: thats great to hear... so it uses the metadata fields? [16:51] <rrodgers> yep - configurable [16:51] <stuartlewis> Can we (could we / should we?) just treat trunk as bleeding edge, all commit away, and fix later if problems arise? (for patches that aren't introducing any architectural changes at least anyway) [16:51] <mdiggory> excellent... just like dryad, very much approve [16:52] <jat_ysu> stuartlewis: then a fix release [16:53] <jat_ysu> ? [16:53] <mdiggory> ouch [16:53] <kshepherd> i thought i'd seen some conflicts between embargos and the delegated admin patch but i could be wrong, will have to check again [16:54] <rrodgers> kshepherd, which embargo code? [16:54] <stuartlewis> No - would all be fixed before 1.6 is released, but just all get our code in there earlier rather than later. [16:54] <kshepherd> rrodgers: JHU, so probably not the patch you're talking about? [16:54] <rrodgers> kshepherd, right - JHU not what I'm using [16:54] <stuartlewis> kshepherd: rrodgers is going to use the Harvard patch. [16:55] <kshepherd> ok, cool [16:56] <stuartlewis> Is there more to discuss with 1.6? Or move to the next topic? [16:56] <mdiggory> running short ton time, next topic [16:57] <stuartlewis> GSOC? [16:57] <mdiggory> sure why not [16:57] <rrodgers> OK on GSOC - I forwarded the request for status report to Andrius [16:58] <rrodgers> I've been on vacation for a few weeks, so I'll be learning also what he's up to.... [16:59] <mdiggory> thank you, I've been pushing some interesting topics from the Northwestern Fedora JCP connector onto you and have had IRC conversations with Andrius that it exists. I'd recommend listening in or lurking in teh activity [16:59] <mdiggory> Just recently, they were load testing it... so that is progressing... [16:59] <rrodgers> thanks - I'm sure he can use good ideas [17:00] <mdiggory> I think there is still a big need for direct mappings between dspace 2.0 and Fedora however [17:00] <mdiggory> so think is work is still very important [17:00] <rrodgers> s/is/his [17:01] <mdiggory> ;-) [17:01] <mdiggory> I will give some status on Gauravs work at this point [17:02] <mdiggory> ARD Prasad has joined the team to mentor him and is working with him to get daily activity reports and feedback [17:02] <mdiggory> Gaurav is working on a status report to give on Frida [17:04] <mdiggory> we are recommending he focus on the database drive inputforms project exclusively instead of continuing onto submissions [17:04] <mdiggory> s/drive/driven [17:05] <mdiggory> without jayan or aaron present, it looks as though we won't get status from them [17:05] <mdiggory> but I will say that the Northwestern project may also inform us on teh REST front as well [17:06] <mdiggory> at least in that we know we need a very clean REST implementation for DSpace initially and that the GSoC project is important [17:08] <stuartlewis> Is that the GSOC update finsihed? [17:08] <mdiggory> and that off the shelf tooling like Sling has its own challenges in how they subvert the meaning of REST [17:08] <mdiggory> well, a nice transition [17:08] <mdiggory> perhaps we can talk about DSUG briefly? [17:08] <stuartlewis> Yes - was about to suggest the same :) [17:08] <stuartlewis> Who's going? [17:09] * stuartlewis is [17:09] * kshepherd isn't :( [17:09] <rrodgers> Lucky dog [17:09] * mdiggory appears to be [17:09] <stuartlewis> (This is the Sweden DSUG in October 14th-16th) [17:09] * mhwood probably not -- our travel budget is halved this year. [17:09] <mdiggory> bad times indeed [17:09] <rrodgers> Yep, I doubt I'll make if for travel budget reasons [17:10] <stuartlewis> We need to work together to try and make sure we cover the bases on 1.6 and 2.0. [17:10] <mdiggory> I think we should get a more conclusive estimate of commiter attendance [17:11] <rrodgers> well, sounds like you have the two bases covered [17:11] <mdiggory> by posting to the dspace-commiter list to get a head count [17:11] <mdiggory> our concern is in what developer related activities would be appropriate for the conference [17:12] <mdiggory> if committer group attendance is significant enough, there should be a meeting of some sort. [17:12] * stuartlewis thinks Tim D might be there too. [17:13] <stuartlewis> I'll email Jonas and try to get an update o nthe programme, and start to work out what technical updates and presentations we need to do for 1.6 and 2.0 at the DSUG. [17:14] <mdiggory> bradmc: do we have anything new on teh Foundation side? [17:15] <rrodgers> mdiggory, not sure he's still here [17:15] <mdiggory> I suspect your correct [17:16] <stuartlewis> Any other topics before the meeting concludes? [17:16] <mdiggory> no [17:16] <jat_ysu> Documentation update [17:16] <mdiggory> oh yea, right [17:17] <mdiggory> most certainly [17:17] <jat_ysu> Brad has email me any and all sections needing attention. They are done. [17:17] <stuartlewis> jat_ysu: Sorry, slipped my mind! [17:17] <jat_ysu> I've gleaned through the complete manual and made updates to typos and just plain wrong data from 1.4.x days [17:18] <kshepherd> hooray! [17:18] <jat_ysu> Now for the work: Ch. 5 (Configure) is being updated completely to match all the components in the dspace.cfg [17:18] <rrodgers> jat_ysu, is your version up somewhere for review? [17:19] <mdiggory> commit it... ;-) [17:19] <jat_ysu> Customizations such as jspui and xmlui will be split into a customization chapter. [17:19] <jat_ysu> http://digital.maag.ysu.edu/jspui/doc [17:19] <jat_ysu> it's last weeks work. [17:19] <rrodgers> thx [17:20] <jat_ysu> Also, I'm working through the print.xsl style to get it a little more tuned due to Configuration's needs. [17:20] <mdiggory> jat_ysu: I noticed a problem with the DRI reference docBook... seems to be poorly formed xml, did you catch that? [17:20] <jat_ysu> I will not leave anything out that is currently there. [17:20] <jat_ysu> Yes... [17:20] <mdiggory> can we also consider adopting usage of the docBook schemas? [17:20] <jat_ysu> My rule is this: if it produces poorly in PDF it needs fixed. HTML is very forgiving. [17:21] <jat_ysu> How so? [17:21] <mdiggory> I've been using XML Mind, but need to change the namespace/schema so that it recognizes it as docBook [17:21] <mdiggory> I will send it to you shortly [17:22] <mdiggory> you tehn actually get WYSIWYG editing capabilities [17:22] <jat_ysu> Gotcha. I have to admit, that at first I thought docbook was going to be cumbersome--but I'm sold. [17:22] <jat_ysu> I'm using </oxgyen> and GoLive to edit. [17:22] <mdiggory> http://www.xmlmind.com/xmleditor/ [17:22] <jat_ysu> got it. [17:23] <jat_ysu> I have FOP-0.94 installed here at YSU so I'm able to generate the end files for my use. After they look correct, I commit to the trunk. [17:23] <mdiggory> http://www.xmlmind.com/xmleditor/screenshots/MathMLSupport.png [17:23] <jat_ysu> mdiggory: some of the issue isn't the docbook xml coding, it is FOP that sometimes burps and generates bad pdfs. [17:24] <jat_ysu> All I want to add is that if you have extensive updates, send them to me and I'll get them in fast.... I'll need the 1.6 stuff when something is committed [17:25] <jat_ysu> Or at least let me know you've added documentation. [17:25] <mhwood> There was some talk about documentation issues last week and I believe you weren't present. About adjustments to JIRA for documentation bugs/requests/patches. [17:25] <jat_ysu> great. [17:25] <mdiggory> I wonder if we can get away with less "shell scripting" in the conversion from docbook to html and pdf? [17:25] <jat_ysu> sorry I wasn't in the office last week. [17:25] <stuartlewis> Yes - there is now a JIRA category for documentation status [17:25] <mdiggory> what! [17:25] <jat_ysu> The shell script that Brad wrote works fine. It generates both at the same time. [17:25] <mdiggory> not in the office? ;-) [17:25] <mhwood> The logbot should have it. Around 12:30 ET, 15-Jul-2009 [17:26] <mdiggory> my concern is that the shell script is platform specific and not part of build process. [17:26] <jat_ysu> Well, behind the scenes, I have other scripts to generate just a chapter to check it out. [17:26] <stuartlewis> (not required, needed, in description, in comments, in attachment(s)) [17:26] <mdiggory> but, sorry I don't want to distract us from the important excellent activity of working on the documentation itself [17:27] <jat_ysu> mdiggory: It depends on what you use for your transformation...I'm using FOP and not DSSSL/Jade. [17:27] <jat_ysu> So you pick your poison and run with it. FOP is java.... [17:27] <jat_ysu> Perhaps FOP could be incorporated into a DSpace JSPUI module. [17:27] <jat_ysu> Okay back to topic. [17:28] <mdiggory> hehe... your gonna start scaring people off [17:28] <jat_ysu> I'll let you all know when I generate a completely new manual after configuration and cusomization sections are revised. [17:28] <mdiggory> I think the JIRA topic is of great importance [17:29] <jat_ysu> Yes, JIRA works--I must have fallen alseep at the wheel. Stuart--Will look at this. Sorry. [17:29] <mdiggory> we should be documenting these activities, especially emails about changes etc... [17:29] <mhwood> Maybe wrap a little Java around the rendering process in place of the shell scripts? Then Maven can pull it all in. "Maintenance tools" sounds like a module.... [17:29] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer)) [17:29] <jat_ysu> Yeah, even just a text file with 'stuff' in it. We can (or I can) glean the necessary documentation. [17:30] <rrodgers> I've got to run - see you all later [17:30] <jat_ysu> One thing lacking is a true index to the manual. I'm not sure for the 1.6 release I can get that built for you all. There's a lot of manual tagging that has to be done. [17:30] * rrodgers (n=rrodg...@pool-173-76-17-204.bstnma.fios.verizon.net) Quit ("Leaving") [17:30] <mdiggory> I think the issue is that theres some file pushing going on in the shell script that make just adopting maven slightly more challenging [17:31] <mdiggory> jat_ysu: Yes, thisis what I mean, having an "index.xml that is hardcoded like this isn't good [17:31] <jat_ysu> Well the documentation has never been part of the installation--are you suggesting that we do that? [17:31] <mhwood> Maybe it would be better to work out some guidelines so that we can all start tagging properly? [17:31] <jat_ysu> index.xml isn't hardcoded.....there are <index></index> tags inside the documents. [17:32] <mdiggory> oh, I misunderstood that then [17:32] <jat_ysu> mhwood: that might be helpful--but for now, the goal (IMHO) is to clean up and get it ready with the 1.6 stuff. [17:33] <mdiggory> no, I didn't... http://scm.dspace.org/svn/repo/dspace/trunk/dspace/docs/docbook/index.xml [17:33] <jat_ysu> I think for the 1.7/2.0 documentation, I could draw up a set of 'standards' that explain the tagging used and more important the type of styles applied via the .xsl sheets. [17:33] <jat_ysu> mdiggory: index.xml is ignored completely for the generating of the PDF and HTML. It was commented out of the book.xml [17:34] <mdiggory> ha! thats good news [17:34] <mdiggory> we should get rid of it [17:34] <jat_ysu> Docbook 4.5 lets us generate a "on-the-fly" sort of index generation by tagging the data directly. [17:34] <mdiggory> yes, we want to use that [17:34] <jat_ysu> If you view book.xml you will find a </index> tag. That lets it (FOP) know what to do. [17:35] <mdiggory> maybe theres much less that needs doing then... [17:35] <jat_ysu> after I'm done editing this huge section, I'll experiment with the index tagging. Might have to through some mix into the style sheet. [17:35] <jat_ysu> no biggie [17:35] <mhwood> Well, somebody has to put all the <index> tags in. [17:36] <jat_ysu> mhwood: maybe. I'm looking at some documentatin that leads me to believe that we might be able to let the machine generate the first level of tags. [17:36] <mhwood> Not a bad idea. The result will seem a little eccentric, but humans should be able to clean it up much more quickly than they can generate it all. [17:37] <jat_ysu> So, I will continue working on this and let you all know how I progres. [17:37] <jat_ysu> Exactly. [17:37] <jat_ysu> Okay, that's all I have to report--can we go home now? LOL [17:37] <stuartlewis> Thanks for the update - and for the documentation work. [17:38] <kshepherd> i wish.. haven't even had lunch yet! ;) [17:38] <mhwood> I must go soon, unless I'm specifically needed. [17:38] <jat_ysu> me too.... [17:38] <stuartlewis> Its going to be much improved for 1.6 which great :) Thanks. [17:38] <mhwood> Yes, <applause/> for the documentation effort. [17:38] <jat_ysu> I hope so...if I can understand it it should work. [17:38] * bradmc (n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace [17:38] <jat_ysu> *blush* [17:38] <mdiggory> yes excellent [17:38] <kshepherd> agreed, it's awesome stuff [17:38] <stuartlewis> Ok - any other topics, or meeting over? [17:39] <mhwood> Sounds like meeting over. [17:39] <jat_ysu> night all [17:39] <mdiggory> jat_ysu: heres an example of the namespace/schema declaration.... [17:39] <mdiggory> http://pastebin.com/m43236300 [17:39] <stuartlewis> Meeting over. Thanks all :) No doubt Brad will post a log to the list. [17:39] <mhwood> Goodbye, thanks!
Transcript of July 29: [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=mdigg...@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. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
