On Thursday 21 January 2010 10:15:05 Tim Donohue wrote:
> I was just informed that our DSpace Developer meeting that took place
> yesterday (Weds, Jan 20) unfortunately was not logged as usual. So, in
> lieu of a full meeting transcript, here's a quick summary of what we
> discussed.
I've attached a transcript from the meeting in case it is useful to anybody.
~Chris
--
Chris Charles
Application Programmer/Analyst
Research Enterprise & Scholarly Communication
University of Guelph Library
519-824-4120 x52974
[Wed Jan 20 2010]
*** You have joined channel #duraspace
[15:02]
*** Topic for #duraspace: Welcome to DuraSpace - This channel is logged -
http://duraspace.org/irclogs/
*** #duraspace: topic set by cwilper, 16:32:05 2009/06/30
*** Users on #duraspace: cccharles grahamtriggs jtrimble tdonohue cbeer mhwood
bradmc awoods kshepherd greg-g cwilper @ChanServ stuartlewis
*** #duraspace modes: +tnc
*** #duraspace was created on Thursday 2009/06/25 7:23:32 PM
<tdonohue> Hi all. When Stuart gets back, we can start the meeting off with
1.6 status updates
[15:03]
<stuartlewis> Shall we start with 1.6? I think we could do with reviewing the
open issues and seeing how they progressing, and if
any need to
be bumped to 1.6.1
[15:04]
<stuartlewis>
http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10020&fixfor=10020
<tdonohue> the first thing that strikes me about that list is that two are
unassigned still: DS-417 and DS-418
[15:05]
<stuartlewis> Claudia and Kim have been looking at 418 - might be quite a big
one unfortunately.
<tdonohue> ok...Stuart, did you want to go down this list and review one by
one, or are there particular ones to review?
[15:06]
<mhwood> I stared at 417 a bit the other day, but I think it may indeed be due
to timezone offsets as surmised in the comments.
<kshepherd> yes, there are a few comments on 418, i'm not quite confident
enough of my theory/stance to grab the job just yet
though ;)
<kshepherd> (would appreciate feedback)
<stuartlewis> Well - can we prune the list first? Jeff - are there any
assigned to you that you want to talk about, or are
they all OK?
<stuartlewis> 418 - my git instinct is to close with can't reproduce, and let
it be re-opened if required?
[15:07]
<stuartlewis> s/git/gut ;)
[15:08]
<kshepherd> ?!
<jtrimble> I'm okay with them now. I've got my bearings for a change. [15:09]
<tdonohue> stuartlewis: Do you mean DS-417
<stuartlewis> jtrimble: Are all the documentation issues assigned to you OK,
or do you need any further input?
<tdonohue> DS-417 was unreproduceable by larry...but it looks like DS-418 is
still in progress by kshepherd, others
<stuartlewis> tdonohue / kshpepherd: Yes, thanks! Typo!
<jtrimble> The biggest one is the authority control, but LCS wrote me a very
extended and detailed email that clears it all up
<kshepherd> heh
*** mdiggory ([email protected]) has joined channel
#duraspace
[15:10]
<kshepherd> the authority control feature *rocks*, btw
<kshepherd> larry++++++++++
<stuartlewis> OK - so everything assigned to Jeff is good.
<tdonohue> Ok, Stuart, do you want to go down the rest of the "open" list of
issues for 1.6 and we can review one-by-one (filtering out
those
assigned to jtrimble)
<mdiggory> Hi everyone
[15:11]
<stuartlewis> Shall we go through the rest? I think outcomes are either: keep
assigned person and get a completion date, assign to
someone
else, bump to 1.6.1
<tdonohue> hi mdiggory - we're reviewing the open issues list:
http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10020&fixfor=10020
<stuartlewis> OK - let's start with DS-239 java.net.MalformedURLException:
unknown protocol: resource
<mdiggory> we were going to invest time into researching this
<mdiggory> but I've not accomplished it yet, tdonohue have you?
[15:12]
<stuartlewis> Is it blocker for 1.6, or could it be bumped to 1.6.1?
<mdiggory> Its been with us since 1.5.2...
<tdonohue> mdiggory: I hadn't had a chance to look at DS-239
<mdiggory> so I might not consider it a blocker, but it would be good to not
have this stuff broken
<stuartlewis> Could you summarise the problem, and how it affects people?
[15:13]
<mdiggory> Cocoon blocks is a great functionality for adding services to
dspace,
<mdiggory> if ti was working
<stuartlewis> E.g. can it be a 'known problem' for 1.6 without affecting too
many people?
<mdiggory> The latest release of the sitemap block for cocoon fixed...
<tdonohue> mdiggory: could it wait for 1.6.1 though, how many folks actualy
use cocoon blocks right now
<mdiggory> DS-253
[15:14]
<mdiggory> in the Servlet response buffering wrapper...
<mdiggory> but using that new version introduced DS-339 as a problem
<mdiggory> which means you can't really do Cocoon blocks
<mdiggory> they don't register properly and webapp in general will not start
now if you try to
[15:15]
<tdonohue> right..understood. the question is, who is really using blocks
right now, besides you :)
<mdiggory> aparentely not many, instead everyone butchers the defualt sitemap
to introduce new services
[15:16]
<tdonohue> i'd vote we save this for 1.6.1, and if mark or I get to it
earlier, great...but, we shouldn't hold up 1.6.0 for it.
<mdiggory> things like opensearch, feeds, etc should have been blocks
<stuartlewis> OK - is everyone happy if we mark this for 1.6.1? (which doesn't
preclude it being fixed in 1.6)
[15:17]
<mdiggory> even google sitemaps... should have been blocks
<mdiggory> anything with /xxxxx other than "/handle"
<stuartlewis> +1 mark it for 1.6.1 (it has never bitten me)
[15:18]
<tdonohue> mdiggory: agreed. but most of us are still learning cocoon -- and
i'll admit to not even fully understanding blocks yet...so,
we're
making small steps
<mhwood> Unfortunately Cocoon 2.2 documentation varies between MIA and
hopeless, so many simply don't know that much about recent
features.
<tdonohue> +1 for 1.6.1
<mhwood> +1 1.6.1
<mdiggory> Cocoon Blocks are the actual implementation that would have aligned
easily with Richard Rodgers "Bricks" presentation / proposal
[15:19]
<mdiggory> mhwood: that is true... :-(
<kshepherd> +1 for 1.6.1
<stuartlewis> OK - we'll punt it to 1.6.1.
<tdonohue> ok, it looks like we have +4 to move DS-239 to 1.6.1
<stuartlewis> Next: http://jira.dspace.org/jira/browse/DS-253
NullPointerException in
HttpServletResponseBufferingWrapper
(Cocoon bug?)
<mdiggory> ok +1
[15:20]
<tdonohue> mdiggory, on DS-253, is your patch worth adding to 1.6.0?
<tdonohue> or, does it need more review?
[15:21]
<mdiggory> it already is
<mdiggory> applied that is.
<stuartlewis> Great :)
<stuartlewis> Can it be closed?
<tdonohue> ok, excellent
<mdiggory> scm.dspace.org 4090 Thu Jul 16 00:28:40 UTC 2009 mdiggory
<mhwood> Ah, good.
<tdonohue> so, mdiggory, we can close DS-253, or are there other outstanding
issues here?
[15:22]
<mdiggory> I think it was also applied to the dspace-1.5.x branch...
<mdiggory> Which suggested a 1.5.3 maintenance release to correct that
stream...
<mdiggory> possibly something to do after 1.6.0
[15:23]
<mdiggory> not sure why the change doesn't show here
<stuartlewis> Can DS-253 be closed though, or does it need to stay open for
the potential 1.5.3 release?
<mdiggory> looking... please continue while I do so
[15:24]
<stuartlewis> Ok.
<stuartlewis> Next: http://jira.dspace.org/jira/browse/DS-365 New DSpace
OAI-PMH Harvester doesn't support OAI gateways that
do not use
"sets"
<mdiggory> @mire can contribute this
<mdiggory> we ahve a fix in the NESCent Dryad repository
<stuartlewis> A fix for DS-365?
<mdiggory> yes
<kshepherd> yep, feel free to reassign
<stuartlewis> OK - Mark: shall re assign to you or Ben B?
[15:25]
<mdiggory> Lets give Ben some credit ;-)
<stuartlewis> OK - assigned to Ben B. Thanks.
<stuartlewis> Next: http://jira.dspace.org/jira/browse/DS-289 OAI-PMH +
OAI-ORE harvesting support
[15:26]
<mdiggory> commited... this should be resolved/closed
<tdonohue> it looks like DS-289 is waiting on Oracle support?
<stuartlewis> Looks like there are patches ready for testing.
<mdiggory> were the patches applied?
[15:27]
<stuartlewis> No, not yet.
<stuartlewis> Is the best we can do, apply them, test postgres is OK, and
trust the submitter that oracle is OK? (we can do a
human read
sanity check of the oracle schema update)
[15:28]
<mdiggory> ok, that would seem important, but I'm not in a position to test
Oracle on this ATM
<tdonohue> stuartlewis: I think so. we don't have enough Oracle users right
now....we need help on that
<stuartlewis> OK - does anyone know the harvesting feature well enough to be
able to give this a quick test?
<tdonohue> Maybe reassign to Andrea, and see if he's willing? (I don't know
it well enough myself)
[15:29]
<mdiggory> You can get a free dev copy of oracle to run locally, and we
(@mire) do have Oracle clients. Just nothing yet on 1.6.0
(clearly
because its not yet released ;-)
<tdonohue> any volunteers to look at and commit this one?
[15:30]
<tdonohue> Ok. I guess I can take it on then for now. At a quick glance this
looks mostly done. Assign to me
[15:31]
<stuartlewis> OK - thanks Tim.
<stuartlewis> Next: DS-440 spiders.txt empty
[15:32]
<stuartlewis> http://jira.dspace.org/jira/browse/DS-440
<stuartlewis> mdiggory: Can you tell us what format this file needs to be in?
<mdiggory> DS-253 can be
closed...
http://scm.dspace.org/trac/dspace/browser/dspace/branches/dspace-1_5_x/dspace-xmlui/dspace-xmlui-wing
<stuartlewis> We could then look at shipping a default file for spiders.txt
[15:33]
<mdiggory> I did apply there as well, it seems to not show up as a JIRA commit
include though
<mdiggory> JIRA bug for tdonohue?
<mdiggory> list of individual spider ips
*** bradmc
(n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com)
has
quit: Read error: 104 (Connection reset by peer)
<stuartlewis> One IP per line?
[15:34]
*** bradmc
(n=bra...@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com)
has
joined channel #duraspace
<stuartlewis> Can they be network classes? e.g. xxx.yyy.
<mdiggory> Yes, one IP per line
[15:35]
<mdiggory> I'm not sure about classes, I didn;t think so
<stuartlewis> mdiggory: Shall we leave assigned to you, or is someone else
wanting to take this on?
<mdiggory> leave it assigned to me, @mire is discussing strategies here
[15:36]
<stuartlewis> OK. Do you have a timeline?
<stuartlewis> E.g. 1 week form now?
<mdiggory> tangent question... stuartlewis your clients for populating the
db... do they filter on this file?
<stuartlewis> No, because the file is empty.
[15:37]
<mdiggory> db meanding solr
<stuartlewis> Could do though.
<stuartlewis> My sciprts just screen out googlebot, yahoo slurp, and MSN bot.
<mdiggory> the file is empty becuase it is populated of the Spiders client
that trolls the logs looking for robots.txt accesses
<mdiggory> probibly a good point for documentation ;-)
[15:38]
<stuartlewis> Problem is, the script want an Apache (apache web server, not
tomcat) log, not dspace log from what I've seen?
<mdiggory> well, depends on where you put your spiders.txt I guess
<tdonohue> mdiggory: yea, that needs documentation please. I didn't know
that spiders.txt file was auto-populated
<mdiggory> I assume we will recommend using the webappp
<mdiggory> trying to come up with a few augmentations to improve some of this
areaease
[15:39]
<stuartlewis> tdonohue: There is a script you can point at an apache web
server log file, and it will look for any IP that has
requested
robots.txt, and add that IP to the list.
<stuartlewis> User-Agent string would be a good one to start with, and should
catch 90% of crawlers.
[15:40]
<mdiggory> keep it assigned to me... I want to escalate it though, and I think
the User Agent stuff should wait until 1.6.1
<stuartlewis> OK - but if we can exclude the three main bots for 1.6, that
would be good.
<stuartlewis> Ok: Next:
<stuartlewis> http://jira.dspace.org/jira/browse/DS-417 1-day (or passed)
embargo dates give error upon submission
[15:41]
<mdiggory> ok,
<stuartlewis> 417: Mark as 'can't reproduce'?
<tdonohue> DS-417: I'd agree, 'can't reproduce'
<mhwood> +1
<stuartlewis> And invite to re-open with steps to reproduce.
<stuartlewis> +1
<tdonohue> +1 to both ideas
<kshepherd> +1
[15:42]
<tdonohue> DS-417: +4, mark can't reproduce and ask submitter for more info
<stuartlewis> Next: http://jira.dspace.org/jira/browse/DS-336 DSpace Services
2.0 Support
<stuartlewis> mdiggory: Is this still complete, awaiting docs?
<mdiggory> complete awaiting docs... yes... I started documenting things in
the confluence space...
[15:43]
<mdiggory> but need to continue to improve upon it.
<stuartlewis> By next week?
<stuartlewis> If we could have most stuff cleared up by next week, that would
be excellent.
<mdiggory>
http://fedora-commons.org/confluence/display/DSTEST/DSpace+Services+Framework
[15:44]
<jtrimble> Mark, can you point to that directly so that it can be copied into
the current documentation?
<mdiggory> just did ;-)
<jtrimble> Thank you
<stuartlewis> Next: http://jira.dspace.org/jira/browse/DS-247 Contribution of
@MIRE Solr Based Statistics Engine to DSpace.
<stuartlewis> mdiggory: Is this the same - just waiting for docs?
[15:45]
<mdiggory> yep, still just docs...
<mdiggory>
http://fedora-commons.org/confluence/display/DSTEST/DSpace+Statistics
<jtrimble> Mark..thanks. Those will get into the docbook by saturday [15:46]
<mdiggory> still could use improvement
<mdiggory> but its a start
<tdonohue> question on DS-247: I'm assuming the old stats stuff is still
sticking around. Do we mark the old stuff as "obsolete" in
some
way?
<stuartlewis> That depends if we want it to be obsolete?
<mdiggory> its still there, its still running, and it can still be viewed
<mdiggory> I would suggest a patch of deprication
[15:47]
<mdiggory> patch = path
<stuartlewis> I think that is a decision that community can make once they
have got 1.6 solr stats and can decide what they want?
<tdonohue> whoops, i actually mean deprecate it...sorry, wrong word
<jtrimble> LOL
<jtrimble> naughty boy
<tdonohue> yea, i'm getting ahead of myself :)
<tdonohue> stuartlewis: that sounds fine
[15:48]
<mdiggory> better than depreciating it
<stuartlewis> Finally:
<stuartlewis> http://jira.dspace.org/jira/browse/DS-423 Ant target
'clean_database' doesn't drop all tables'.
<stuartlewis> I'm guessing CLaudia is really busy as she hasn't applied her
patch. Anyone else have the time to check it over and
apply?
<mdiggory> ugh... ant
[15:49]
<tdonohue> stuartlewis: I can apply this patch...it's all DB SQL patches
<mdiggory> what about Browse tables?
[15:50]
<tdonohue> good question. no idea
<stuartlewis> tdonohue: Th anks - will reassign
<stuartlewis> Doesn't the browse scripts handle all the tidying of browse
tables?
<mdiggory> not sure you can calculate the whole table space... I usually just
drop the database and start over
[15:51]
<tdonohue> hmmm..yea, why do we have an 'ant clean_database" anyways
<jtrimble> convenience for the neophyte?
[15:52]
<tdonohue> I guess. though you could argue "dropdb dspace" is easier :)
<stuartlewis> OK - so we have 17 open issues, all assigned except DS-418 i18n
broken in jspui
<tdonohue> well, i can look into this, see if we can get 'ant clean_database'
to work right
[15:53]
<jtrimble> Oh Im agreeing, but the newbies that don't know SQL from SQUAT...
<tdonohue> jtrimble: true
<stuartlewis> 12 of which are documents awaiting treatment from Jeff's lawn
mower, weed killer, and manure.
<jtrimble> should the ant clean_database do the same exact thing, more or
less?
<jtrimble> <=== GUILTY
[15:54]
<stuartlewis> 5 others left that require a bit of work.
<stuartlewis> RC2 is getting closer! :) (docs don't need to be completed
for RC2)
<jtrimble> They need tender loving care, watering, and some pruning.
<jtrimble> Oh they will be
<mdiggory> SQUAT... structured query update and t...?
<stuartlewis> jtrimble: Excellent - thanks :)
<tdonohue> should we contact Claudia about DS-418? Is there a way to get a
fix for 1.6.0 or should this wait for 1.6.1?
[15:55]
<stuartlewis> So - here's the BIG question - can we have all this done by next
week? 27th?
<stuartlewis> 418 is probably going to the big sticking point. Ideally it
needs fixing for 1.6.
<tdonohue> well, then it needs assigning :)
[15:56]
<jtrimble> T==Thwat
<stuartlewis> The (not so good) alternative is to roll back
http://jira.dspace.org/jira/browse/DS-294 and look at
fixing the
whole thing in 1.6.1?
<mdiggory> why doesn't claudia commit it?
[15:57]
<kshepherd> the patch doesn't solve the entire problem
<stuartlewis> Commit what? This is turning into a bigger problem which has
been exposed by patches such as DS-294
<stuartlewis> My patch is only a partial fix.
<mhwood> Does what we have make anything worse?
[15:58]
<kshepherd> the larger problem is spread over... all of JSPUI
<stuartlewis> The whole jspui i18n fragility is now being exposed.
<tdonohue> eek
<mdiggory> label won't fix?
<kshepherd> i was hoping for a consensus on which I18nUtil.getMessage() to use
<stuartlewis> kshepherd
<stuartlewis> kshepherd: Sounds like we should talk about that now?
<kshepherd> (half of JSPUI uses context/eperson locale, the other half
extracts browser locale settings from page request)
[15:59]
<mdiggory> move to 1.6.1?
<tdonohue> kshepherd: so, do you think this could be resolved by making that
consistent?
<tdonohue> (or even partially/mostly resolved)
[16:00]
<kshepherd> sorry, phone call
[16:01]
<stuartlewis> Ok - I'll talk to Kim and Claudia offline about this, and we'll
try to make a recommendation about how best to patch
over the
big holes for 1.6.
[16:02]
<kshepherd> right.. um.. yeah, i think consistency in how we get i18n messages
is the big thing
<stuartlewis> Are we still aiming for all issues to be resolved by next week's
meeting?
<tdonohue> based on kshepherds comments on DS-418, I think his ideas sound
good
<tdonohue> +1 for resolving by next week (I think I can finish mine by then)
<stuartlewis> Ok - then we can hopefully cut an RC2 at the end of the week.
[16:04]
<tdonohue> mdiggory: how are you for next week?
<kshepherd> i'm scared to promise anything ;) but i will make best effort at a
patch for DS-418 by then
<stuartlewis> kshepherd: Give us all a shout if we can help out.
<mdiggory> sounds sensible. +1
<tdonohue> mdiggory: can you pass on the goal to ben bosman as well? [16:05]
<mhwood> +1
<kshepherd> this is the priority for locale detection that i'm proposing:
Eperson settings, then browser locale, then DSpace
default.
<mdiggory> if you assigned it to him, he will see it.
<stuartlewis> kshepherd: Sounds sensible.
<tdonohue> mdiggory: it's assigned to him...more wanting to see if he thinks
its doable by next week, or if we should reassign
[16:06]
<stuartlewis> I know better than my browser, my browser knows better than the
system.
<mhwood> Why does eperson trump browser
<stuartlewis> Because *I* am the eperson.
<stuartlewis> *I* trump my browser.
<kshepherd> mhwood: beacuse an eperson probably knows what language they speak
and could be using any number of PCs/browsers
<kshepherd> (my thinking at least.. always happy to be overruled!)
<mhwood> OK, I'm convinced.
[16:07]
<tdonohue> that makes sense to me...lets the user customize it for themselves
across many browsers
<stuartlewis> Do we have a fourth option, which is the language selected in
th e session using the language tags? WOuld this
trump my
default eperson preference?
* mhwood wonders what year it was the last time he used a browser he hadn't
configured.
<mdiggory> I am not an EPerson! I am an iPerson.
<mhwood> I am not an EPerson; I am a free man!
[16:08]
<kshepherd> mhwood: heh, i'm thinking more of public terminals,
corporate/campus workstations
* tdonohue wonders if mdiggory is owned by Apple
<kshepherd> stuartlewis: i hadn't remembered that option
[16:09]
<mdiggory> apparently, I spend most of my day on an iPhone :-(
<stuartlewis> kshepherd: I think it needs to be a 4th option, and trumps all.
<kshepherd> that sounds fair..
* stuartlewis wonders how long an 'mvn package' of DSpace takes on an iPhone?
<stuartlewis> Meeting closed? Anything else to discuss?
[16:10]
<kshepherd> i might post this topic to dspace-tech and get feedback from
admins and users who run multilingual IRs already
<tdonohue> kshepherd: good idea
<stuartlewis> kshepherd: Good idea.
<mhwood> Yes
<tdonohue> Meeting is closed. Thanks all. If anyone is heading to dev8D, let
me know...be glad to meet up in London
*** jtrimble ([email protected]) has quit: "Leaving"
[16:11]
<kshepherd> cheers all
<tdonohue> i'm excited for 1.6...getting closer and closer
<stuartlewis> +1 :)
<stuartlewis> It has been a long time coming, but will be awesome once
released!
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
