Timestamps are in GMT/BST.
[2:33] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) has joined #duraspace
[2:33] * mdiggory_ (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit (Read error: 104 (Connection reset by peer))
[3:51] * mdiggory (n=mdiggory@cpe-76-176-188-83.san.res.rr.com) Quit ()
[4:43] * sbayliss (n=IceChat7@78-86-0-203.zone2.bethere.co.uk) has joined #duraspace
[4:43] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 54 (Connection reset by peer))
[4:43] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[5:51] * grahamtriggs (n=trig01@195.128.10.96) has joined #duraspace
[6:27] * sbayliss (n=IceChat7@78-86-0-203.zone2.bethere.co.uk) Quit (Read error: 110 (Connection timed out))
[7:02] * sbayliss (n=IceChat7@78-86-0-203.zone2.bethere.co.uk) has joined #duraspace
[8:15] * awoods_ (n=awoods@pool-72-66-9-76.bltmmd.fios.verizon.net) has joined #duraspace
[8:23] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[8:28] * sbayliss (n=IceChat7@78-86-0-203.zone2.bethere.co.uk) Quit (Read error: 110 (Connection timed out))
[9:37] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[9:37] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[10:41] * cbeer (n=chris@137.149.226.142) has joined #duraspace
[11:39] * cbeer (n=chris@137.149.226.142) Quit ()
[12:16] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) has joined #duraspace
[12:59] * grahamtriggs (n=trig01@195.128.10.96) has left #duraspace
[13:12] * cbeer (n=chris@137.149.227.104) has joined #duraspace
[13:31] * cbeer (n=chris@137.149.227.104) Quit ()
[15:56] * rrodgers (n=rrodgers@pool-173-76-17-204.bstnma.fios.verizon.net) has joined #duraspace
[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=jeffreyt@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=bradmc@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=bradmc@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=bradmc@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=rrodgers@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=bradmc@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!
[17:40] * mhwood (i=mwood@mhw.ulib.iupui.edu) has left #duraspace
[17:40] <jat_ysu> Thanks mark...I
[17:40] * jat_ysu (n=jeffreyt@MAAG127.MAAG.YSU.EDU) has left #duraspace
[20:26] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:26] * bradmc (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: 104 (Connection reset by peer))
[21:12] * mhwood (i=mwood@mhw.ulib.iupui.edu) has joined #duraspace
[21:13] * mdiggory (n=mdiggory@64.50.88.162.ptr.us.xo.net) Quit (Read error: 110 (Connection timed out))
[22:13] * mhwood (i=mwood@mhw.ulib.iupui.edu) Quit ("Leaving.")
[23:22] * bradmc_ (n=bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit ()
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
