Timestamps are in GMT/BST.
[2:18] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[3:56] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[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
[4:09] * pvillega (~pvillega@86.47.50.67) has joined #duraspace
[8:13] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:40] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[9:14] * pvillega_ (~pvillega@62.77.170.185) has joined #duraspace
[9:14] * pvillega (~pvillega@86.47.50.67) Quit (Read error: Connection reset by peer)
[9:21] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[9:43] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[9:48] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[10:55] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[10:57] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[11:19] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[12:38] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[12:38] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Read error: Connection reset by peer)
[12:38] * mdiggory_ is now known as mdiggory
[12:41] * pvillega_ (~pvillega@62.77.170.185) Quit (Remote host closed the connection)
[14:37] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[15:01] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:01] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has left #duraspace
[15:01] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has left #duraspace
[15:01] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:52] * mdiggory_ (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory_)
[15:53] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:54] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:55] <tdonohue> Hi all -- DSpace Dev Meeting will be starting here in ~5min. Agenda is here: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-05-05
[15:56] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[15:57] * ksclarke (~kevin@184.39.8.146) Quit (Ping timeout: 246 seconds)
[16:00] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[16:00] <tdonohue> For those who just entered -- DSpace Dev Mtg Agenda: http://fedora-commons.org/confluence/display/DSPACE/DevMtg+2010-05-05
[16:01] <PeterDietz> anyone know if there is an "end" date for OR10 registration, website mentioned nothing.
[16:01] <tdonohue> Main topics for today are 1.6.1 updates and 1.7.0 scheduling/planning. But, before we get started, any announcements/questions/agenda items?
[16:01] <tdonohue> PeterDietz: good question -- I'm not sure if there is an "end" date, but can ask around
[16:01] <kshepherd> looks good to me, i think JIRA reviews are the most important thing right now
[16:02] <mdiggory> We should add some planning fro GSoC to the list
[16:03] <tdonohue> Ok. well, let's get started with 1.6.1 updates first (since that is most pressing). kshepherd, want to update us on the latest? Are there issues you want immediate review on (we could post them for quick reviews here, if needed)
[16:03] <kshepherd> ok, here comes a paste
[16:03] <mdiggory> I was also hopin to see jtrimble trumbling about to discuss documentation
[16:03] <kshepherd> 1.6.1 release update: currently 48 open JIRA bugs affecting 1.6.0, 30 of them unassigned.
[16:03] <kshepherd> This morning, I've done some committing of fixed issues that were sitting open waiting for review for a long time. I will be pretty busy in svn and JIRA from now until Saturday (Sunday NZ time).
[16:03] <kshepherd> As far as actual release coordination goes, I've not been as good on the communication front as I intended, and I apologise for that.
[16:03] <kshepherd> Although the CHANGES file for 1.6.1 isn't huge, and probably won't be a lot bigger by next week, I think we've still covered nearly all the critical bugs in 1.6.0, and most of the major issues that would have been causing people to delay their upgrades from 1.5.x. So I'm still keen to push for a cut and release next week if others agree.
[16:03] <kshepherd> I'd also like to add something about the length of time we leave good patches sitting in JIRA...
[16:03] <tdonohue> mdiggory: jtrimble said he couldn't make it today -- he emailed me offline...we can talk about docs after 1.6.1 stuff
[16:04] <mdiggory> k
[16:04] <mdiggory> kshepherd: Something not in the JIRA I want to get in is a small upgrade to dspace-services
[16:05] <tdonohue> fyi for all: 1.6.1 in JIRA: http://jira.dspace.org/jira/browse/DS/fixforversion/10030
[16:05] <mdiggory> yes, looking
[16:05] * richardrodgers (~richardro@dhcp-18-111-30-22.dyn.mit.edu) has joined #duraspace
[16:05] <kshepherd> I think i'm probably the biggest culprit for this, so i'm half suggesting it and half making sure that i'm on the right track -- i (and others) have a tendancy to leave issues open in JIRA, with good patches attached, for a long time even when it's clear that they work and that no more peer review is coming/needed
[16:05] <mdiggory> I'll take DS-556
[16:05] <kshepherd> also, i think people find it far easier to test an svn area like dspace-1.6.x or trunk than download and test individual patches attached to JIRA issues
[16:06] <kshepherd> so i'm sorta pushing for a more "gung ho" attitude to committing small bug fixes to trunk/branch -- if it works, do it, and at the very worst we might have to revert a few changes
[16:06] <mdiggory> yes, I remember us talking in IRC about having a faster track for work that is commiter driven
[16:07] <tdonohue> ok. So, it looks like we still have 24 unresolved issues scheduled for 1.6.1 -- kshepherd, are you suggesting we reschedule some/many of these for later releases, or do many already have patches?
[16:07] <kshepherd> i don't mean we stop testing/reviewing, just that leaving stuff sitting there for a month doesn't look good and doesn't help us keep ontop of things
[16:08] <PeterDietz> so for committers to commit decent fixes, which allows reviews to happen in fisheye. where as volunteers patches. either way, make a jira ticket first
[16:08] <mdiggory> I think we want to avoid the extreme seen in places like the Solr JIR, they have issue open for the last 4 years still
[16:08] <kshepherd> tdonohue: well, when we first talked about a release date for 1.6.1, we said "early may" and that we should stick to that, with any patches not committed getting automatically rescheduled to 1.6.2. does that still sound reasonable?
[16:08] * 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:08] <mdiggory> kshepherd: I do think that it is your role to shove issues off the list if they won't be tractable in 1.6.1
[16:09] <kshepherd> tdonohue: i guess part of what i'm asking is "how many bug fixes is it worth releasing a minor version for?"
[16:09] <kshepherd> mdiggory: yeah true, i probably need to get more gung ho there too ;)
[16:09] <richardrodgers> Isn't one question whether there are *must have* fixes for 1.6.1?
[16:09] <kshepherd> richardrodgers: definitely
[16:09] <mdiggory> kshepherd: if its a really bad issue.... just one
[16:09] <kshepherd> i'll be going through everything closely before this Sunday and making sure the showstoppers/majors really do make it in
[16:10] <tdonohue> yea, I see it similar to richardrodgers. There's no set number of issues to fix for 1.6.1 -- just be good to get those ones we deemed "must have" resolved. Other than that, I'm fine with rescheduling still open issues for a 1.6.2 or 1.7.0 release
[16:10] <kshepherd> ok, excellent
[16:10] <kshepherd> that makes JIRA reviews even more important :)
[16:10] <kshepherd> i'm happy to keep going at some after the meeting's over, if we run out of time
[16:11] <mdiggory> I'm all for the approach, as long as a 1.6.2 is taken with the same stance...
[16:11] <mdiggory> IE we would probibly have a 1.6.2 later in the summer/fall if there were more showstoppers that emerged
[16:11] <tdonohue> As for the other point, I think any work/patches created by committers should also be given a "fast track" -- i.e. just run it by one other committer (minimally) and if he/she approves and thinks it's good, commit it -- if there is doubt, bring that issue to a meeting and we can review it as a group
[16:12] <kshepherd> cool
[16:13] <tdonohue> so, if there are issues/patches that are still highly doubtful or need discussion, feel free to bring them up now (or we can discuss later on in this meeting, if you need to gather them together)
[16:13] <mdiggory> I think we should be more direct that committers "should" operate in this manner and not in the same manner as non-commiter contributors
[16:13] <tdonohue> mdiggory -- you mean we should make this a "rule" -- committer patches get a "fast track"?
[16:14] <mdiggory> IE commiters do not create patches and leave them rotting in issues, the commit with the JIRA issue number in the commit log
[16:14] <mdiggory> we have enough work to do keeping up with contributors
[16:14] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[16:14] <kshepherd> cool, i like this idea
[16:14] <tdonohue> yea -- i'm fine with making that more explicit, and suggest that as a "best practice"
[16:15] <mdiggory> I think we need review, but where kshepherd is heading is that such review can be better enabled if the code being reviewed is already in the svn
[16:15] <kshepherd> sometimes i'm just nervous about submitting something that hasn't had explicit approval from 2+ other people, but considering most of those patches are tiny bugfixes that are trivial to revert, and i've always tested them thoroughly anyway, i don't know why i end up leaving the issues open so long :P
[16:16] <tdonohue> Oh -- update from jtrimble about the 1.6.1 Doc Issues -- he said the documentation JIRA tickets should be committed to trunk on Sun Evening
[16:16] <mdiggory> especially with tools like crucible and fisheye
[16:16] <kshepherd> yes, if anyone's not aware of the Fish Eye / Crucible tabs in JIRA, check them out
[16:16] <mhwood> kshepherd: so I'm not the only one who does that.
[16:16] <kshepherd> looks like you need to sign up on the hosted crucible site to get an account associated with committer username..?
[16:16] <kshepherd> mhwood: heh, i knew there were others out there ;)
[16:17] <tdonohue> yea...the crucible integration we have now is with the hosted site -- but, DuraSpace will be working soon(ish) to merge our JIRA + Fedora's into a single DuraSpace JIRA + DuraSpace Crucible, etc
[16:17] <mdiggory> yes, because otherwise you can't make reviews
[16:18] <mdiggory> but you can remap th username on a per svn basis
[16:18] <mdiggory> tdonohue: sounds good, but why not use it if its free?
[16:18] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[16:19] <mdiggory> if Atlassian gave a away free confluence/jira hosting for OS projects, I be all over it
[16:20] <tdonohue> i'm not against using it -- I'm just stating that we're working on making your *one login* work for Confluence, Jira, Crucible, etc. (basically all our Atlassian products)
[16:20] <mdiggory> ok, good point, that would be beneficial
[16:20] <mdiggory> http://jira.dspace.org/jira/browse/DS-516 <-- kshepherd this needs to be a priority in 1.6.1
[16:21] <kshepherd> yes
[16:21] <mdiggory> http://jira.dspace.org/jira/browse/DS-203 <-- not important, should be pushed out
[16:22] <tdonohue> Are there any other 1.6.1 issues we should review / assign, so that we can crank them out before next week?
[16:22] <kshepherd> mdiggory: would you be able to open a placeholder issue for the pending dspace-services contribution as well?
[16:22] <mdiggory> yes, doing it...
[16:22] <kshepherd> if anyone's has a tidy fix for ds-401, i'd love to hear it
[16:23] <tdonohue> kshepherd: isn't that one of the DCDate issues? I thought, based on last week's logs (which I read) you all decided to push those back to 1.7.0 (or 1.6.2)?
[16:23] <tdonohue> http://jira.dspace.org/jira/browse/DS-401
[16:24] <kshepherd> mdiggory: re DS-516 -- you're happy with stuart's patch? (for 1.6.1 anyway, perhaps not 1.7.0)
[16:24] <kshepherd> tdonohue: yes, it's one of the DCDate issues
[16:24] <mdiggory> Well, I have a pile of stuff on my workspace... stuarts stuff doesn't quite cleanup the existing scripts
[16:25] <richardrodgers> Perhaps we should 'doc' patch (i.e. warn) about date issues in the meantime
[16:25] <mdiggory> it just enables running drun in the launcher
[16:25] <kshepherd> tdonohue: and i guess it's not the worst one (that was DS-497), but i still think it's pretty nasty..
[16:25] <tdonohue> Perhaps we should create a DCDate Issue and attach all the related "child" issues to that one... I'd suggest delaying for a better fix, and just warn people (like richardrodgers just suggests)
[16:25] <mdiggory> I may really need th at date patch...
[16:25] <mdiggory> but do not wait for me if I cannot get to evaluating the solution
[16:25] <kshepherd> i think i was more pushing for us to look closely at DCDate for 1.7+, but still make small fixes to teh issues we're seeing now, in the meantime
[16:26] <tdonohue> ok -- I see. I think that's reasonable, kshepherd, if we can find someone to help make smaller patches ;) otherwise, I'd say they should all be delayed by default
[16:26] <kshepherd> DS-497 definitely needed committing, for example (which i did earlier this morning)
[16:28] <kshepherd> since it's 30min in already, i'm happy to wait until post-meeting to keep talking DCDate and 1.6.1 priorities with people if you want to carry on with teh rest of the agenda
[16:28] <tdonohue> So, basically, if we wanted to get 1.6.1 out next week (say May 14th release day), then we really need to "freeze" around May 11 -- so that we can at least do some minimal testing of everything together.
[16:29] <richardrodgers> yea, what is our test strategy?
[16:29] <kshepherd> sounds good to me
[16:29] <tdonohue> well, I'd actually like to see if we can set a "freeze" day :) as you mentioned, kshepherd, we cannot keep accepting patches/fixes forever :)
[16:30] <tdonohue> richardrodgers asks a good question -- I was assuming a more "ad hoc" mini-testathon, but we could run a full scale testathon as needed (the only difference I see between the two is pre-planning & time)
[16:30] <kshepherd> richardrodgers: there's a small enough list of changes that we could probably simply test each one systematically, as well as some basic "did we break anything else" tests
[16:30] <kshepherd> open to ideas though
[16:30] <mdiggory> kshepherd: added http://jira.dspace.org/jira/browse/DS-571
[16:31] <tdonohue> we can also use http://demo.dspace.org to "bang on it" in a more centralized fashion -- but, we'd want to "freeze" the code before that
[16:31] <richardrodgers> kshepherd: sounds right, I just meant we shouldn't stick you with it ;)
[16:32] <mdiggory> tdonohue: if we can get hudson installed on demo, then we can deploy an automatic rebuild when the svn changes
[16:32] <tdonohue> So, in my mind -- we could either (A) Freeze on 11th, release on 14th (2-3days testing). OR (B) Freeze on 14th, Release on 21st (week of testing). I'm fine with either, I'd just like to choose one :)
[16:33] <mdiggory> and ksclarke and I have additional experience
[16:33] <mdiggory> to get that working once it was there
[16:33] <tdonohue> mdiggory: you can have hudson if you install it. As I mentioned to email to dspace-commit, the committers can all have full access to demo.dspace.org (I'm not going to "play admin" for that server, I just don't have the time)
[16:33] <kshepherd> i like (A) since we announced "early may", but not too bothered
[16:33] <mdiggory> ok, I missed that
[16:34] <mdiggory> I'll look up the email... is anyone else here messing around with demo?
[16:34] <tdonohue> demo.dspace.org is an Amazon EC2 server that DuraSpace set up for the Dspace committers -- it is unmanaged, unless the committers want to manage it (I'm the only one who has done anything on it thus far though)
[16:35] <keithg> automatic builds and deploys would be cool
[16:35] <kshepherd> so far i just use my own EC2 box for random testing but i wouldn't mind helping out with a shared one, too
[16:35] <kshepherd> hudson would indeed be very cool
[16:35] <kshepherd> any other votes for tdonohue's release date proposals?
[16:35] <kshepherd> "(A) Freeze on 11th, release on 14th (2-3days testing). OR (B) Freeze on 14th, Release on 21st (week of testing)
[16:36] <kshepherd> I'm +1 on (A)
[16:36] <richardrodgers> I'd vote for (A) if we can quantify all outstanding bugs by then
[16:36] <mdiggory> I'm +1 on (B)
[16:36] <tdonohue> I'm good with either, to be honest. ;)
[16:36] <PeterDietz> A++ as its been stable with whats been committed thus far
[16:37] * stuartlewis (~stuartlew@gendig21.lbr.auckland.ac.nz) has joined #duraspace
[16:37] <mhwood> I'll observe that B misses "early May".
[16:37] <tdonohue> uh-oh...here comes stuartlewis :)
[16:37] <stuartlewis> :)
[16:37] <kshepherd> mhwood: that's really my only problem with B
[16:38] <kshepherd> but if A puts too much pressure on ds-571 then i'm happy for B
[16:38] <tdonohue> I'm not too concerned about missing "early May", as in reality, we haven't made any real "official" announcement on an exact timeframe (at least not to dspace-general...there's been plenty of talk on dspace-devel)
[16:38] <richardrodgers> Since there isn't a real strong driver, go for B if anyone wants, like mdiggory
[16:38] <tdonohue> so, I'm willing to "lean" by a week, if it ends up making for a better 1.6.1
[16:39] <keithg> +1 B, primarily because of the longer testing period
[16:39] <stuartlewis> Just reading the logs - I'll have 516 sorted by the weekend (1.6.1 add the dsrun capability and patch the current scripts to call dspace dsrun, and 1.7 remove the scripts)
[16:40] <kshepherd> sounds like B has enough support.. and the only reason to go A is to try and fit with original announcement, so let's go for B
[16:40] <stuartlewis> B +1
[16:40] <mhwood> OK, B +1
[16:40] <mdiggory> I need to leave in about 10 minutes...
[16:40] <tdonohue> Ok..done. I'll actually send out a more official announcement then to the community (kshepherd, I'll be sending you an email about). 1.6.1 will be on May 21st
[16:41] <kshepherd> cool
[16:41] <mdiggory> sounds good, thnx
[16:41] <kshepherd> i'm happy to discuss more 1.6.1 stuff post-meeting so you can carry on with teh rest of the agenda
[16:41] <tdonohue> I'd like to also discuss 1.7.0 if we can today (I know there are many other things we also need to discuss)
[16:41] <tdonohue> Has everyone had a chance to read through my "brainstorm" here: http://fedora-commons.org/confluence/display/DSPACE/DSpace+Release+1.7.0+Notes
[16:42] <stuartlewis> Yes - looks great.
[16:42] <kshepherd> yeah, and i do agree strongly with the "No incompelte features in Trunk, ever" best practice
[16:42] <tdonohue> Essentially, we still don't have a Release Coordinator, and I'm wondering whether we could try a "Committer Coordinated" release process, which would require tighter scheduling, but would lessen the burden on any *one* of us
[16:43] <mhwood> Just now seeing it, but looks good so far.
[16:43] <kshepherd> (and no, this doesn't clash with what i was saying earlier about JIRA issues, because i was talking about tiny bugfix patches there ;))
[16:43] <stuartlewis> I still prefer having a release coordinator - they do a lot of the PR work.
[16:43] <stuartlewis> So the RC doesn't need to be a committer if we could find someone outside the group?
[16:44] <kshepherd> could we perhaps farm the PR work off to the dspace outreach ambassadors, or something like that?
[16:44] <stuartlewis> Or ask one of them to take on the RC role? I can think of several people in that group who would be ideal.
[16:44] <tdonohue> PR work need not be *done* by a release coordinator though...it could be managed by that "Community Advisory Team" which we've been discussing (though it's been a while, that idea is still bouncing around amongst the outreach group / ambassadors)
[16:44] <mdiggory> I need to see what we will be getting out of GSoC before I commit to any of these other projects. We need to have a features discussion that is a special topics meeting.
[16:45] <stuartlewis> tdonohue: Agreed, just in the absence of such a group, a single RC would be good to get the community working together.
[16:45] <kshepherd> hmm, either dspace-devel is very slow today or i'm missing mail for some other reason..
[16:45] <mdiggory> I can live without a RC if we have a fixed schedule. Not so big on PR being a Release Coordinators job
[16:46] <stuartlewis> PR maybe the wrong term - perhaps 'advocate' would be better.
[16:46] <mdiggory> Different RC's have approached the job differently in the past. theres no "one way" to do it
[16:46] <tdonohue> stuartlewis: yea, Val & I are hoping to get that group organized "soonish" though -- it's had good feedback on both sides, and we're hoping to move forward with that. Any other PR work could come from Val & I in the meantime as needed
[16:47] <stuartlewis> It's not a biggie, I'm happy with or without one, but I think we need to address the public iterface side of things if we don't have one.
[16:47] <stuartlewis> tdonohue: That's good news :)
[16:47] <tdonohue> yea -- agreed. I'm just also pointing out that we having had an RC volunteer, so moving forward without one is probably better than sitting around doing nothing ;)
[16:47] <mdiggory> Having the Community Advisory Team doing the promotional/logistical announcements and discussion is fine as long as they are being accurate.
[16:48] <richardrodgers> tdonohue: agreed. Getting later volunteers would be OK
[16:48] <tdonohue> mdiggory -- obviously, there would need to be accuracy -- the idea is that that Advisory team would likely have 1-3 committers on it anyways (or at least have committers in touch with them -- so announcements would still be coming via committers)
[16:49] <tdonohue> Any thoughts on the Timeline I proposed? Good/Bad? http://fedora-commons.org/confluence/display/DSPACE/DSpace+Release+1.7.0+Notes
[16:50] <PeterDietz> I do see value of RC for feature-based releases though.
[16:50] <mdiggory> Its ok, I want to know where/how we will manage the list of New Features and if we are needing agreement on their inclusion... or do people vote with their feet.
[16:50] <richardrodgers> tdonohue: only thing is generally releases right around a holiday get lost....
[16:51] <stuartlewis> Timeline looks great :)
[16:51] <tdonohue> PeterDietz: I'll mention, I'm perfectly willing to have an RC for 1.7 -- I'm just trying to "push" the point a bit, and show another option, since we haven't had a volunteer -- if we have a volunteer step forward, then we can have an RC, but we need to move forward either way
[16:51] <mdiggory> Well, I go back to my previous position that doing the release after the holiday in January gives us more time and less "lost"
[16:52] <kshepherd> i like the timeline, though i agree with pushing the release date so it's closer to "back at work" time for University general staff
[16:53] <mhwood> People who are keen to try it before January can always export what is there.
[16:53] <tdonohue> So, are we now rethinking the idea of a Dec release for 1.7? My only thought is that we want to try and schedule Testathon so that it is *not* over a holiday/break (otherwise we'll get fewer testers)
[16:53] <stuartlewis> Would having the release before Christmas give us that extra little push to make sure it was released on time?
[16:54] <richardrodgers> It would be good to have it wrapped up by mid-Dec. The actual promotion date is a bit fungible
[16:54] <kshepherd> hm, good point about testing period
[16:54] <mdiggory> well, if we have a nice Testing framework... we may have more testathon testing tht we can bargan with
[16:54] <tdonohue> +1 stuartlewis -- that's what I was hoping.
[16:54] <mhwood> I thought the idea was: testathon stays where it is, but release date slips to early January.
[16:54] <mdiggory> acceptable
[16:54] <stuartlewis> (and two major releases in one year will look good for us)
[16:55] <tdonohue> mhwood - I guess I don't see the benefit of pushing the release date to Jan then? what does it give us? more bug fixing time? or just not having to cut it in mid-Dec?
[16:55] <mdiggory> ok, sorry guys, have to go, will catch up later.
[16:56] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) Quit (Quit: mdiggory)
[16:56] <kshepherd> perhaps delaying 'promotion' date like richardrodgers suggested is a better idea, if we're worried about the release "getting lost"
[16:56] <kshepherd> but still freezing/releasing in dec
[16:57] <tdonohue> yea.. I can understand that. Or promoting both *before* the holidays and just *after*
[16:57] <richardrodgers> kshepherd: that's what I meant
[16:57] <kshepherd> yeah
[16:57] <mhwood> It was suggested that mid-late December releases drown in the general year-end slowdown and holiday feeling.
[16:57] <stuartlewis> Drown in what sense?
[16:57] <kshepherd> mhwood: which means mid-late December testathons are probably a disaster..
[16:57] <kshepherd> brb, smoke
[16:58] <stuartlewis> Drown in developer effort to help with the final mile, or drown in no one upgrading once it is released (which isn't an issue?)
[16:58] <tdonohue> I was just looking forward to a "Happy Holidays from DSpace" release announcement ;)
[16:58] <stuartlewis> "The 12 days of Christmas / DSpace" - 12 new features, one unwrapped each day
[16:59] <PeterDietz> ooh, almost like symfony+jobeet
[16:59] <mhwood> Yes, maybe a second announcement in January to renew interest after everybody is back and able to take on significant tasks (like upgrading DSpace).
[16:59] <tdonohue> I'll also note that the *real goal* here is to release on Dec 3 (assuming we only need RC1 -- but, we have a buffer to allow for an RC2)
[17:01] <tdonohue> So, it sounds like...most are in favor of "cutting" the release in Dec, but are worried that it could get ignored or missed (which means, we may also need to do a Jan release announcement). Is that right?
[17:01] <kshepherd> yep +1
[17:01] <mhwood> Yes
[17:02] <stuartlewis> Personally I don't think people will miss it, or forget about it if we release in Dec. It just means they'll wait until Jan/Feb to do the upgrade.
[17:02] <kshepherd> can't hurt to remind everyone in Jan anyway ;)
[17:02] <stuartlewis> A lot of poeple also seem to wait until 1.x.1 to upgrade anyway, so the sooner the better, so we can get cracking with 1.7.1
[17:02] <richardrodgers> I'd like to announce in 2010, certainly
[17:03] <tdonohue> excellent, sounds like we have a general plan, and general 1.7.0 timeline as well.
[17:04] <tdonohue> I've noticed we're over time...so, feel free to head out if you have to. The official meeting can be considered closed
[17:04] <richardrodgers> the other concern I had is if folks *do* install in weeks following Dec 17, I won't be around to help...
[17:04] <kshepherd> i also agree with both the proposed 1.7 code committing rules
[17:04] <tdonohue> excellent. Yes, please add any more comments to wiki page if you have them
[17:05] <tdonohue> kshepherd, do you want to "unofficially" meet with those of us that have time now? on 1.6.1?
[17:05] <stuartlewis> Yes - those rules are sensible, and will help alleiviate slippage a little while awaiting things to be completed.
[17:05] <kshepherd> yeah sure
[17:06] <tdonohue> thanks for the feedback all -- the "rules" were a collaboration between brad & I, and I'm glad to hear that others agree
[17:08] <kshepherd> PeterDietz: re: DS-509 -- you're intending to i18nize this before committing?
[17:08] * 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:08] <tdonohue> http://jira.dspace.org/jira/browse/DS-509
[17:08] <PeterDietz> yeah, i wasn't sure what i18n namespace to use. I'm going to do org.dspace.statistics.util.LocationUtils.unknown.country and .city
[17:08] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[17:09] <PeterDietz> since I've finally broken the 1st commit seal, I should be better about making progress on my issues
[17:10] <stuartlewis> I'll work on the following issues before next week: DS-516, DS-242, DS-498
[17:10] <kshepherd> that sounds fine to me.. would pay to involve Claudia and other regional i18n maintainers
[17:11] <stuartlewis> What about DS-550? Leave for 1.7? http://jira.dspace.org/jira/browse/DS-550 (since nothing is broken, it is just an improvement)
[17:12] <PeterDietz> yep, she's given me her thumbs up
[17:12] <kshepherd> yep i'm happy to keep that flagged for 1.7
[17:12] <stuartlewis> ok
[17:12] <tdonohue> stuartlewis: DS-550 is already scheduled for 1.7 -- I'd vote leave it there, as it's an improvement, not a bug :)
[17:12] <stuartlewis> That's what I thought - was just checking since it's on my to-do list
[17:13] <kshepherd> i'd like to get DS-559 in, though i need to study the datasets being generated by dspace-stats more closely
[17:14] <kshepherd> (another i18n issue - this time with statistics)
[17:14] <kshepherd> (UI display of statistics data, i should have said)
[17:14] <PeterDietz> and DS-522 (converting apache logs to solr format logs), thats a new feature, so once thats cleaned up / accepted, that would be targeted for 1.7
[17:15] <kshepherd> PeterDietz: yep agreed
[17:15] <tdonohue> yea, DS-559 might be one that would have to fall to 1.6.2 (if we have one) or 1.7, unless someone can get to it before May 14 freeze date
[17:15] <mhwood> Must go. On advice, I moved a couple of my items from 1.6.1 to 1.7
[17:16] <tdonohue> mhwood -- sounds good, thanks!
[17:16] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has left #duraspace
[17:16] <richardrodgers> I posted new Embargo doc in DS-430 - would love feedback so we can get it in
[17:16] <kshepherd> PeterDietz: i've updated the affects/fix versions in JIRA for DS-522 for you
[17:18] <tdonohue> richardrodgers: I read through DS-430 just yesterday. Sounds good, but I'd like to see an *example* for setting up an embargo. So, actually a step by step process of what you would do to define/enable your embargo with a real-life example.
[17:18] <tdonohue> richardrodgers: the background and explanation is wonderful though -- just needs an example
[17:19] <richardrodgers> tdonohue: OK, will provide
[17:19] <kshepherd> yep an example would be cool, the doc looks great though
[17:19] <tdonohue> thanks, that'd be great
[17:19] <richardrodgers> The problem is not reproducing all the input_forms and other doc
[17:20] <richardrodgers> Almost all is standard DSpace administration/configuration
[17:20] <tdonohue> yea, but maybe you could just give an example of something to insert into input_forms.xml, etc.
[17:21] <richardrodgers> I'll give it a shot
[17:21] <tdonohue> So, (1) Add metadata fields (2) config embargo in dspace.cfg, (3) add field to input-forms.xml, etc
[17:21] * ksclarke (~kevin@184.39.8.146) Quit (Quit: Leaving.)
[17:22] <tdonohue> kshepherd: anything else that needs some eyes right now? or a volunteer?
[17:22] * kshepherd notes he's using the embargo framework in a very different way than it was intended, but it's working well ;)
[17:23] <kshepherd> DS-524 needs checking and probably an XMLUI volunteer
[17:23] <kshepherd> http://jira.dspace.org/jira/browse/DS-524 - Eperson netID is lost editing the record from the webUI
[17:24] <kshepherd> richardrodgers: a few smaller institutions have seemed a bit nervous that the embargo feature is a framework they need to extend rather than use "out of the box", but once it's explained that it's better to have the flexibility for everyone to implement their own embargo policies, they seem to understand. i'm also hoping that some early adopters with fairly generic embargo policies can share their setter/lifter plugins with the
[17:25] <tdonohue> hmm...DS-524 might need more discussion, and may have to be pushed back. I'm wary of adding more configs just for configs sake (as you can tell from my comment on the issue)
[17:25] <kshepherd> yeah
[17:26] <richardrodgers> kshepherd: yes, I'm doing some outreach by priming the pump - I wrote another setter & will donate it
[17:26] <kshepherd> i don't use any alternative auth systems so i don't have a qualified opinion on the actual change in behavoiur
[17:27] <tdonohue> kshepherd -- yea, robintaylor and I agreed on DS-524, that we really should just be treating netID similar to email. I'm still not convinced otherwise (which is why it probably needs more discussion -- if anyone has a real reason why we need these configs, then it'd be good to understand it better)
[17:29] <tdonohue> (i.e. I'm not sure I totally understand andrea's explanation for DS-524 -- he may have a point that I'm just not understanding)
[17:29] <kshepherd> if the workaround right now is that people just need to have ldap.enable = true (regardless of actually using LDAP) then it's probably something people have already learned to workaround, and may not be a critical issue for 1.6.1
[17:30] <kshepherd> am i understanding correctly?
[17:30] <kshepherd> i need to go pretty soon
[17:30] <tdonohue> that's fine -- I'm just sticking around as long as you need to ;)
[17:31] <tdonohue> yea, I think the workaround you described is correct. This may have to remain a "known issue" until we can discuss it more
[17:31] <richardrodgers> I've got to run also - thanks all
[17:31] * richardrodgers (~richardro@dhcp-18-111-30-22.dyn.mit.edu) Quit (Quit: richardrodgers)
[17:31] <kshepherd> i can't see any other urgent unassigned stuff -- there's a pretty big bug in XMLUI collectino display when teh collection has a license, but YinYin has submitted a good simple fix that i'll commit today
[17:32] <tdonohue> excellent -- that's good news, that means things are starting to wrap up nicely!
[17:32] <tdonohue> thanks for all your hard work as the 1.6.1 release coordinator -- you've been doing a great job
[17:33] <kshepherd> well :/ i've been slack on the communication front. but i'll try and pick that up this week
[17:33] <kshepherd> if anyone feels like they're "out of the loop" or are not sure where things stand, please let me know and i'll try and update everyone on dspace-devel
[17:33] <tdonohue> no prob. I'd suggest you definitey *should* send an email to dspace-devel in the next day or two announcing the "freeze date"
[17:34] <kshepherd> i'll also try for an unofficial JIRA review on Saturday 8th 20:00GMT (Sunday 9th 8am NZT) if anyone is interested
[17:35] <kshepherd> no obligation
[17:35] <tdonohue> I'm supposed to write up an update for 1.6.1 & 1.7 for dspace.org site today/tomorrow -- so, I'll be sending out an update on the release day being on the 21st (and I'll copy you in on what I write up, so you can modify/tweak as needed)
[17:35] <kshepherd> cool
[17:36] <tdonohue> I'll admit, I don't tend to be online much on weekends (family time)...but, would be willing to chat next week as needed
[17:37] <kshepherd> yeah.. just thinking that a review next week is going to be very close to freeze date
[17:38] <kshepherd> but no probs anyway, i realise that timing doesn't suit most people. i'll be doing some work then anyway
[17:38] <tdonohue> true -- understood...I can see if I can pop online on Sat. Otherwise, if you need anything from me, I'll be online on Mon (obviously)
[17:39] <tdonohue> ok...I gotta head out of here now too...so, thanks for the updates and hard work!
[17:39] <kshepherd> right, the emails with their little red exclamation marks are piling into my inbox, time to go attend to some IR administrators :)
[17:39] <kshepherd> yep me too
[17:39] <kshepherd> cheers all
[17:40] <keithg> bye
[17:41] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: keithg)
[17:42] * stuartlewis tends to ignore little red exclamtion marks - I decide what's important in my inbox, not the senders!
[17:43] * PeterDietz likes that gmail doesn't let senders do anything my filters weren't designed to do
[17:43] <stuartlewis> That's just one of my little pet hates.
[17:44] <kshepherd> stuartlewis: heh yeah same here
[17:44] <kshepherd> everything's always urgent
[17:44] <stuartlewis> That's true!
[17:44] <kshepherd> can turn in to a "boy who cried wolf" situation ;)
[17:45] <stuartlewis> Hopefully 'life up north' with only one set of people to make happy will be less stressful :)
[17:46] <kshepherd> heh, i'm mostly kidding anyway, everyone i work with is realistic
[17:53] <grahamtriggs> stuartlewis: I've nothing against people being able to flag that something is important to them - but not when they set it on every mail they send as default
[17:58] <stuartlewis> I hate people who set read receipts on every email too. Important emails maybe, but every email?! I just ignore them. It's up to me whe nI read the email, I don't have to tell you I've read it.
[17:58] * tdonohue plots to send several urgent messages to both grahamtriggs and stuartlewis just saying "hi"
[17:58] <kshepherd> lol
[17:58] <kshepherd> time for more coffee
[17:59] * tdonohue heading offline for a while...bye all
[17:59] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
[18:23] * Dan_Davis (~43f22e74@gateway/web/freenode/x-smpxwmzwguyinycx) Quit (Quit: Page closed)
[18:48] * mdiggory (~mdiggory@64.134.220.84) has joined #duraspace
[19:32] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[20:21] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[20:42] * ksclarke (~kevin@184.39.8.146) Quit (Ping timeout: 260 seconds)
[20:45] * mdiggory (~mdiggory@64.134.220.84) Quit (Quit: mdiggory)
[21:21] * ksclarke (~kevin@184.39.8.146) has joined #duraspace
[22:13] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[23:58] * ksclarke (~kevin@184.39.8.146) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.