Timestamps are in GMT/BST.
[1:51] * awoods (~awoods@pool-173-66-22-133.washdc.fios.verizon.net) Quit (Ping timeout: 265 seconds)
[3:05] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[4:06] -hubbard.freenode.net- *** Looking up your hostname...
[4:06] -hubbard.freenode.net- *** Checking Ident
[4:06] -hubbard.freenode.net- *** Found your hostname
[4:06] -hubbard.freenode.net- *** No Ident response
[4:06] [frigg VERSION]
[4:06] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[6:02] * grahamtriggs (~trig01@80.169.130.178) has joined #duraspace
[7:34] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[8:02] * awoods (~awoods@pool-173-66-110-175.washdc.fios.verizon.net) has joined #duraspace
[8:32] * bradmc (~bradmc@dhcp-18-111-18-170.dyn.mit.edu) has joined #duraspace
[9:25] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:26] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[9:50] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[9:51] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:55] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[9:56] * krnl_ (Andrius@83.171.18.74) has joined #duraspace
[10:03] * cwilper (~cwilper@173-85-168-197.dsl1-erie.roch.ny.frontiernet.net) Quit (Quit: This computer has gone to sleep)
[11:30] * cwilper (~cwilper@173-85-168-197.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[12:25] * bradmc (~bradmc@dhcp-18-111-18-170.dyn.mit.edu) Quit (Quit: bradmc)
[13:13] * grahamtriggs (~trig01@80.169.130.178) has left #duraspace
[14:04] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:06] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[14:06] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[14:11] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (Quit: scottatm)
[14:35] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[14:52] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[15:48] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:51] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:52] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[15:56] * kshepherd nurses coffee
[15:56] <tdonohue> In about 4 mins, we'll be starting the DSpace Developers Meeting here. If anyone has any topics to add to the agenda I sent out (see http://sourceforge.net/mailarchive/message.php?msg_name=4BAA244C.2000206%40duraspace.org), feel free to post your topic suggestions
[15:57] * caryn_ (~80c8e115@gateway/web/freenode/x-sajqxlgjunmlongu) has joined #duraspace
[15:58] * bollini (~chatzilla@host240-211-dynamic.17-87-r.retail.telecomitalia.it) has joined #duraspace
[16:01] <tdonohue> ok...we may as well get started. First thing is to welcome two more committers! Welcome to keithg (Keith Gilbertson) and Robin Taylor (who wasn't able to make it today)! They join PeterDietz as our latest additions
[16:01] * stuartlewis claps joyfully
[16:01] <keithg> hi
[16:02] * keithg smiles
[16:02] * tdonohue joins stuart in clapping
[16:02] <mhwood> Welcome! Unfortunately I have to go right now but will try to get in later in the hour.
[16:02] <tdonohue> bye mhwood -- see you later on
[16:02] <bollini> welcome
[16:02] * grahamtriggs would join in the clapping, but can't type at the same time
[16:03] <tdonohue> Ok. the next item is to mention that our Wiki migration (from MediaWiki to Confluence) is on track for sometime mid-next week (likely 30th or 31st)
[16:03] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[16:04] <tdonohue> we'll be announcing the Wiki migration schedule officially later this week. But, obviously, we'll have to 'lock down' the current wiki for a few days while we migrate to Confluence
[16:04] <tdonohue> We'd also appreciate all the help we can get. DuraSpace and a few other volunteers are leading the migration and cleanup. But, if you have any time late next week, we'd appreciate more help!
[16:04] <stuartlewis> Whats the URL of the new wiki? (or will it be renamed to wiki.dspace.org?)
[16:05] <tdonohue> it will still be wiki.dspace.org
[16:05] <tdonohue> the old one will be made read-only, and be moved to oldwiki.dspace.org (until it's no longer necessary to keep around)
[16:05] <tdonohue> any other thoughts/questions about the wiki migration?
[16:06] <keithg> will people with accounts on the old wiki have their accounts automatically migrated to the new wiki?
[16:06] <grahamtriggs> are the confluence accounts linked to jira?
[16:06] <tdonohue> keithg: Unfortunately, no. The accounts won't carry over. You'll have to recreate your account in the new wiki
[16:07] <PeterDietz> but the up side is that creating a jira account has a captcha to reduce spammers
[16:07] <tdonohue> (but, if you already have an acct on www.fedora-commons.org/confluence/ , then you'll be able to use that acct -- we'll be sharing the Confluence now with Fedora & DuraSpace)
[16:07] <grahamtriggs> what PeterDietz meant to say is that creating a Jira account has a captcha to reduce the number of normal people with 20/20 vision that can register
[16:08] <PeterDietz> And I forgot that grahamtriggs is living in autopilot, with google autoresponding for him.. which sometimes misses the captcha
[16:08] <tdonohue> grahamtriggs: Right now, Confluence Accts are not linked to JIRA -- they are on separate servers, etc.
[16:09] <grahamtriggs> Google's OCR is better at dealing with Captcha than I am
[16:10] <bollini> google OCR... could be interesting to make a filtermedia plugin with it :-)
[16:10] <tdonohue> Ok...if they are any other questions about wiki migration let me know offline (or "on line" later)
[16:11] <tdonohue> Next Topic: April's Special Topic Mtg. Any suggestions on a topic to cover in that meeting? We've had a couple ideas come up in other meetings which I've started to pull together here: http://wiki.dspace.org/index.php/Special_Topics
[16:11] * kshepherd is half in another meeting
[16:12] <kshepherd> keithg: welcome!
[16:12] <tdonohue> (please feel free to add topics to the wiki list....those are just some I've pulled out of recent IRC/email discussions)
[16:14] <tdonohue> Is there anything in particular you all feel is "most pressing"? A discussion of either 'asynchronous releases / modularization' or 'what is 2.0 / how to start to get there' both seem to be hot topics. Any others?
[16:14] <stuartlewis> Have we come to any consensus yet on the previous special topic meetings we've had? (have missed a couple of meetings, so am out the loop slightly)
[16:14] <tdonohue> stuartlewis: last special topics mtg was about Release Procedures. We came to two general consensus:
[16:15] <tdonohue> (1) Scheduled releases are a good thing -- we decided to schedule 1.7 for Dec 2010 (I'll be sending a call for a release coordinator for 1.7 this week)
[16:16] <tdonohue> (2) The Community Advisory Team idea (http://wiki.dspace.org/index.php/ReleaseAdvisoryTeamProposal) was also considered a good thing -- right now we're waiting on the DSpace Outreach Group (Val's leading) to also look at that proposal and provide feedback, etc
[16:16] <stuartlewis> Great - sounds good.
[16:16] <tdonohue> so..I think on the Release Procedures we're in a good place right now -- we just need to keep pushing those forward
[16:18] <tdonohue> so, i'm open to suggestions on next topics....do we dig more into modularization (Graham & Mark D's ideas)?, do we start to map out a clearer 1.6 to 1.7 to...2.0 roadmap?
[16:19] <stuartlewis> 1.7 / 1.8 etc roadmap would be good.
[16:20] <tdonohue> ok. sounds like a good full-meeting topic (and may even carry into later meetings) :) Others agree?
[16:20] * 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:21] <kshepherd> yep
[16:21] <caryn_> sounds good
[16:21] <keithg> yes
[16:21] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:22] <tdonohue> Ok -- sounds like a consensus. We'll make April's Special Topics Meeting (first Weds -- April 7) on the topic of DSpace RoadMap (1.7 and beyond)
[16:23] <tdonohue> If you have some time before that meeting, or have any poignant questions for us to discussion, please add to the wiki: http://wiki.dspace.org/index.php/Special_Topic
[16:23] <kshepherd> i'm always interested in the modularity stuff.. not so much the asynchronous updates, but just looking at what @mire did with dspace-stats, for example, so we can stop stuffing things in trunk and getting told off by Mark ;)
[16:23] <kshepherd> dspace-solr, i should say
[16:24] <tdonohue> kshepherd -- I agree, and we could always schedule a second Special Topics meeting in April about that (no reason we cannot have two). But, I need mdiggory to speak up on that one, and suggest that he can lead the discussion :)
[16:25] <stuartlewis> We also need to start to think about how we maintain 1.6 - when we make 1.6.x releases. The bugs are starting to come in now, so would be good to perhaps get a 1.6.1 out in a month or two.
[16:25] <tdonohue> Any other topics anyone wants to bring up?
[16:25] <kshepherd> yeah i'd like to see 1.6.1 soon
[16:26] <bollini> I'm too
[16:26] <tdonohue> we can do it soon. we just need a 1.6.1 Release Coordinator ;) Any interest kshepherd or bollini?
[16:27] * kshepherd suddenly looks busy
[16:27] <bollini> mmm... I like only the .2 :-)
[16:27] <tdonohue> (reminder, 1.6.1 is a bug fix release -- so, it shouldn't need too much coordination. Mostly a matter of keeping things on track and assigning things in JIRA, etc)
[16:28] <kshepherd> yeah ok go on then, i can do .1, andrea can do .2 ;)
[16:28] <tdonohue> A bug fix release is a good way to try out the coordinator role
[16:28] <tdonohue> yea! thanks kshepherd! We'll put you down for 1.6.1 RC
[16:28] * stuartlewis starts clapping again, this time for kshepherd :)
[16:29] <grahamtriggs> imho, if we're doing a bug fix release, we should be strict on a timeframe for when it needs to be out. If we're moving to timed releases, we have to have the courage of our convictions, and give ourselves the time / space to actually do it
[16:29] <tdonohue> grahamtriggs: good thoughts.
[16:30] <tdonohue> any suggestions for a 1.6.1 timeframe? Reminder that kshepherd now holds veto power as 1.6.1 RC ;)
[16:30] <kshepherd> yeah i see what you've done there :P
[16:31] <stuartlewis> 4 to 6 weeks?
[16:31] <kshepherd> beginning of June would be nice, at the latest
[16:32] <tdonohue> 6 weeks would put us at beginning of May
[16:32] <kshepherd> sounds good to me
[16:32] <stuartlewis> Some idiot (I'm looking at myself here!) managed to break IP Auth in 1.6, and no doubt a few other nasties will arise like this in the next few weeks. Bugs that are easy to fix, so we could release in 6 weeks or so and have a useful release.
[16:32] <tdonohue> that seems reasonable to me as well
[16:32] <kshepherd> we may not get enough real-world use/testing in to catch a large number of bugs by then
[16:33] <kshepherd> but theres always .2
[16:33] <bollini> I agree
[16:33] <stuartlewis> A lot of people also wait for the first bug fix release before upgrading, so releasing that will get us more people upgrading.
[16:33] <grahamtriggs> does 'the beginning of' something sound like it will give us an excuse to slip it back a bit? I think I prefer the idea of a 'by the end of', to reinforce the idea of an endpoint
[16:33] <tdonohue> yea...but, at least we'd be able to get out the "big bugs" (like IP Auth) -- even if we don't catch all of them
[16:33] <stuartlewis> So "1.6.1 - due in May"? We're committing to May, but non-commital about exactly when! :)
[16:34] <kshepherd> i'm adding the 'list / abort all workflow tasks' admin feature from JSPUI to XMLUI for 1.6.1 too
[16:34] <kshepherd> that'll be done today though
[16:34] <tdonohue> grahamtriggs: Ok. how about we say 6 weeks from this Friday, which is Friday, May 7 (if my count is right)
[16:35] <tdonohue> it could be a trial of whether we can all stay on time/target -- if it gets pushed back, fine...we'll know to leave more time for 1.6.2
[16:35] <kshepherd> i actually thought that in teh last meeting people were saying the bugfix releases shouldn't be time-driven like the major ones
[16:35] <kshepherd> but obviously we need to get it out fairly quickly
[16:36] <caryn_> kshepherd: that was my recollection as well... thought i was just missing something
[16:36] <tdonohue> kshepherd: yea, that was the decision, you were right. So, really, it's up to you if you'd like to schedule this out *exactly* or more tentatively...
[16:37] <tdonohue> even if we schedule it out *exactly*, you won't get complaints if it goes past that date (we won't announce a release date publicly until we're ready)
[16:37] <kshepherd> well, nothing wrong with changing our minds.. ;)
[16:37] <tdonohue> kshepherd: if you do get complaints, then the complainers can help you fix the last bugs! (looking at grahamtriggs) :)
[16:37] <grahamtriggs> we can't 'leave more time for 1.6.2', if we're going to hit an end of year 'next version'. that's part of the religion with timed release - we have to be brutal about what we do and want makes the cut
[16:38] <bollini> I think that the 1.6.1 should go out as soon as possible with all the major bugs fixed (4 weeks are good to discover more important bugs too if any)
[16:38] <tdonohue> grahamtriggs: agreed. that was a slip of language. I didn't mean to imply we could push back indefinitely on either 1.6.2 or 1.6.1.
[16:38] <kshepherd> hm
[16:39] <bollini> the 1.6.2 could be useful only if we see a delay in the 1.7.0 release or if more bugs arise
[16:39] <kshepherd> well i think a 6-week release for 1.6.1 is fine
[16:40] <bollini> there is a cost to manage a 1.6.1, 1.6.2 release and go ahead with the development of a 1.7.0 release too
[16:40] <tdonohue> kshepherd: I think that sounds reasonable to me as well. Which puts us at early-May for 1.6.1, and would mean that 1.6.1 would essentially be about 2 months after 1.6.0 (which also seems reasonable)
[16:41] <kshepherd> in other projects, i've tended to decide on a number of bugs / amount of work per bugfix release
[16:41] <kshepherd> rather than trying to guess how many bugs we'll discover/fix in a 6-week timeframe
[16:41] <kshepherd> but in this case i don't think it'll be a prob
[16:42] <PeterDietz> When does the "idea fetching" for 1.7 features kick off?
[16:44] <tdonohue> PeterDietz: if you have ideas, you can already start posting them in JIRA. We need to get a 1.7 RC in place before we officially decide on too much though -- and the SpecialTopics meeting on April 7 (see above) on RoadMap could be a place to also touch on that
[16:46] <tdonohue> so, it sounds like we have a consensus on 1.6.1 in 6 weeks, with kshepherd leading. That means we'll need to start scheduling bugs to be fixed for 1.6.1 in JIRA and assign ones that need work (kshepherd, you obviously have lead on that -- let myself or Stuart, the previous RC, know if you need suggestions/help)
[16:47] <tdonohue> anything else? otherwise we could use the next 10-15mins for a quick JIRA review to start to catch up?
[16:47] <kshepherd> ok sounds good
[16:48] <tdonohue> Ok. let's do a JIRA review for the last 10 mins, and see if we can get through 5 or so recent issues: http://jira.dspace.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10020&resolution=-1&created%3Aprevious=-6w&status=1&assigneeSelect=&sorter/field=created&sorter/order=ASC
[16:48] <tdonohue> We last reviewed DS-494
[16:50] <tdonohue> Reminder on Voting: +1 = keep the issue open (suggest a version to release under or someone to assign to, if you can). -1 = close this issue, it's invalid in some way, 0 = unsure
[16:50] <tdonohue> Broken link in the documentation section 8.2.3. : http://jira.dspace.org/jira/browse/DS-495
[16:51] <kshepherd> once we've figured out where that pdf has gone, we can just assign this to jeff for 1.6.1
[16:51] <stuartlewis> +1, but no idea what the link should be
[16:51] <kshepherd> google doesn't seem to know where it is either
[16:52] <keithg> +1
[16:52] <kshepherd> +1
[16:52] <tdonohue> +1 - Hmm...I'll look into that link. Maybe this still exists someone off dspace.org
[16:53] <tdonohue> Title Browse index has initial/definite articles showing up : http://jira.dspace.org/jira/browse/DS-496
[16:53] <kshepherd> ah yes, i exchanged a few emails with jeff on this
[16:53] <kshepherd> it never occured to me to configure title indices the way he did
[16:54] <tdonohue> yea...as you can see from my comment on that one, I was a bit stumped as well.
[16:54] <grahamtriggs> I think it might just be a bug in the link generation
[16:55] <tdonohue> grahamtriggs: something you could fix? or point us in the right direction with?
[16:55] <grahamtriggs> Probably... I need to actually go back and look at the code though
[16:55] <kshepherd> really?
[16:55] <bollini> mmm...
[16:56] <bollini> I'm working on a new infrastructure to make more general the processing of metadata in the browse/splash page
[16:56] <bollini> assign the issue to me...
[16:57] <bollini> I will take a look the next week
[16:57] <tdonohue> ok. will assign DS-496 to bollini.
[16:57] <PeterDietz> So would correct behavior for DS-496 be for the link to not have The+... or for the link to The+ to actually work
[16:57] <tdonohue> Date month and day get default values when user returns to describe form : http://jira.dspace.org/jira/browse/DS-497
[16:58] <kshepherd> to me it just seems as though the stopwords that are taken out of the indexed 'textvalue' when jeff does that non-standard title index are causing the links to be incorrect
[16:58] <tdonohue> PeterDietz: good question on DS-496.
[16:58] <bollini> PeterDietz: my first response is... both
[16:58] <bollini> it should work in both way according to the user configuration
[16:59] <tdonohue> Any quick thoughts on DS-497? This will be the last one: http://jira.dspace.org/jira/browse/DS-497
[17:00] <grahamtriggs> kshepherd: there isn't much point guessing at it - it's down to whether the value or the sort value should be used to generate the links, and how that should reference the map to the items.
[17:00] <kshepherd> yes
[17:00] * mhwood1 (~Mark@adsl-99-162-52-233.dsl.ipltin.sbcglobal.net) has joined #duraspace
[17:00] <kshepherd> people are used to titles being specific strings that always stay intact, including stopwords
[17:00] <PeterDietz> 496: So: type=title value=The+Art+of+Fugue... So long as title == The+Art+... then we're good, but if his filter turns it to trimmed_title == Art+Of+..., then the browse should be trimmed_title
[17:01] <kshepherd> DS-497: I haven't noticed that, i'll have to test it myself as well
[17:02] <tdonohue> Ok...we'll just leave DS-497 open for more testing. If anyone wants to take it on, feel free to assign it to yourself.
[17:03] <kshepherd> DS-496: i think i missed the part where 'sort' had anything to do with it
[17:04] <tdonohue> We've run over already. So, the meeting is officially adjourned. But, feel free to keep discussing DS-496, if you have the time :)
[17:04] <kshepherd> http://rspace.maag.ysu.edu:8080/jspui/browse?type=title&order=ASC&rpp=20&value=The+Banshee shows no results
[17:05] <kshepherd> http://rspace.maag.ysu.edu:8080/jspui/browse?type=title&order=ASC&rpp=20&value=Banshee shows "The Banshee"
[17:06] <bollini> the problem should be related to this code
[17:06] <bollini> http://rspace.maag.ysu.edu:8080/jspui/browse?type=title&order=ASC&rpp=20&value=The+Art+of+Fugue%2C+BWV+1080%2C+Contrapunctus+4
[17:06] <bollini> sorry...
[17:06] <bollini> else if (field.equals(titleField))
[17:06] <bollini> {
[17:06] <bollini> metadata = "<a href=\"" + hrq.getContextPath() + "/handle/"
[17:06] <bollini> + items[i].getHandle() + "\">"
[17:06] <bollini> + Utils.addEntities(metadataArray[0].value)
[17:06] <bollini> + "</a>";
[17:06] <bollini> }
[17:06] <grahamtriggs> yes, because the 'sort value' is used to access the map, but the (display) 'value' is used in the link. If the link used the 'sort value', it would work
[17:06] <bollini> I think that we don't go inside the block
[17:07] * caryn_ (~80c8e115@gateway/web/freenode/x-sajqxlgjunmlongu) Quit (Quit: Page closed)
[17:07] <bollini> mmm... no graham I don't think that the sort matter
[17:07] <grahamtriggs> but there is an implication, if you have the two different display values, with the same sort value, that they both resolve to the same list of items
[17:07] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: spring soiree)
[17:07] <grahamtriggs> so it may be better to make the 'value' the link into the map, instead of the 'sort value'
[17:08] <bollini> we should go to the item page, or I'm making some mistake?
[17:09] <grahamtriggs> no - these are metadata lists... the unique values contained within a particular metadata field across all the items - that links to a 'second level' browse of the items that contain that metadata term
[17:09] <grahamtriggs> think author list -> items with that author -> actual item page
[17:09] <bollini> ohhh I see
[17:09] <bollini> sorry
[17:10] <kshepherd> yeah.. we're used to doing title indexing differently, so this example jeff's given us is a bit different to normal
[17:12] <grahamtriggs> I can't remember off hand what issues where encountered whilst implementing the links that led us to the current implementation, which is why I don't just want to say 'course of action A' is the correct approach
[17:12] <bollini> yes... it is a little strange but it should work... if no other can look to it before than the next week I'm volunteer
[17:13] <grahamtriggs> there could be a couple of different things that we can do here, and it needs looking at the code to decide which is the right way to go
[17:13] <kshepherd> bollini: cool thanks
[17:14] <bollini> grahamtriggs: I have done a lot of work on the map/browse stuff for the authority support, I could also have added some bugs ;-)
[17:15] <grahamtriggs> now I know who to blame, even if it was my fault. Especially if it was my fault :)
[17:16] <bollini> :-D
[17:16] <kshepherd> my gut feeling would be that we should keep sort value (ie. "Art+of+Fugue,+BWV+1080,+Contrapunctus+4") as the string, and fix the link generation to match
[17:16] <kshepherd> but like you say.. careful testing/thinking is probably needed ;)
[17:18] <bollini> we should have seen similar issues when ignoring upper/lower case
[17:18] <bollini> anyway, we need to think on it ;-)
[17:18] * 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:19] <kshepherd> it's just interesting to me that we haven't seen this before
[17:19] <kshepherd> i guess most other common metadata indices like subject/keyword tend not to have long strings starting with stopwords
[17:22] <grahamtriggs> Upper/lowercase issue is probably why we ended up with make in the sort value the map key - it's less fragile than using the display value (with the caveat that two different display values can link to the same list as they have identical sorts)
[17:23] <kshepherd> mm..
[17:23] <kshepherd> grahamtriggs: so you're leaning towards keeping sort value and tweaking link generation?
[17:23] <bollini> well folks I need to leave... I will check the transcription tomorrow to see if anyone save me to fix the graham mistakes :-D
[17:24] <kshepherd> haha
[17:24] <kshepherd> run while you can!
[17:24] <grahamtriggs> kshepherd: I said I'm staying on the fence until I've looked over the code :)
[17:24] <kshepherd> heh yes, very sensible. ;)
[17:25] <bollini> bye
[17:25] * bollini (~chatzilla@host240-211-dynamic.17-87-r.retail.telecomitalia.it) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819])
[17:27] <kshepherd> time for nicotine, caffiene and last.fm
[17:28] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:29] * mhwood1 (~Mark@adsl-99-162-52-233.dsl.ipltin.sbcglobal.net) has left #duraspace
[17:41] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[17:45] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[18:49] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[18:49] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[18:49] * mdiggory_ is now known as mdiggory
[19:53] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[20:13] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[20:31] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Ping timeout: 246 seconds)
[20:31] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Ping timeout: 246 seconds)
[20:31] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (*.net *.split)
[20:31] * krnl_ (Andrius@83.171.18.74) Quit (*.net *.split)
[20:31] * scottatm (~scottatm@peat.evans.tamu.edu) Quit (*.net *.split)
[20:31] * cwilper (~cwilper@173-85-168-197.dsl1-erie.roch.ny.frontiernet.net) Quit (*.net *.split)
[20:32] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (*.net *.split)
[20:32] * scottatm (~scottatm@peat.evans.tamu.edu) has joined #duraspace
[20:32] * cwilper (~cwilper@173-85-168-197.dsl1-erie.roch.ny.frontiernet.net) has joined #duraspace
[20:32] * krnl_ (Andrius@83.171.18.74) has joined #duraspace
[20:32] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:32] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[20:32] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[20:36] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[22:04] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Ping timeout: 246 seconds)
[22:04] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (*.net *.split)
[22:05] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) has joined #duraspace
[22:06] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[22:19] * cwilper (~cwilper@173-85-168-197.dsl1-erie.roch.ny.frontiernet.net) Quit (Quit: Leaving)
[22:43] * mdiggory (~mdiggory@rrcs-76-79-212-182.west.biz.rr.com) Quit (Quit: mdiggory)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.