Timestamps are in GMT/BST.
[1:05] * ksclarke (~kevin@12.50.87.66) has joined #duraspace
[1:05] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[1:14] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[5:18] * ksclarke (~kevin@12.50.87.66) Quit (Quit: Leaving.)
[6:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[6:35] -card.freenode.net- *** Looking up your hostname...
[6:35] -card.freenode.net- *** Checking Ident
[6:35] -card.freenode.net- *** Found your hostname
[6:35] -card.freenode.net- *** No Ident response
[6:35] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:35] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:35] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:55] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[7:09] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[7:19] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[11:49] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[13:22] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[13:23] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:22] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:34] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
[14:46] * ksclarke (~kevin@airport-grey.nescent.org) has joined #duraspace
[14:53] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[14:58] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[15:01] * bradmc_ (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[15:01] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[15:01] * bradmc_ is now known as bradmc
[17:26] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[17:43] * grahamtriggs (~grahamtri@62.189.56.2) has left #duraspace
[19:46] * elinstangeland (56097ad4@gateway/web/freenode/ip.86.9.122.212) has joined #duraspace
[19:46] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[19:47] <elinstangeland> Hi folks :)
[19:47] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[19:49] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[19:50] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:52] <tdonohue> Hi elinstangeland
[19:52] <elinstangeland> :) Just checking that I got the connection right, haven't done this since I was a student.
[19:53] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[19:53] <tdonohue> Reminder to all, DSpace Devel Mtg will be starting here at top of the hour. Agenda at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-12
[19:57] * cccharles (~chris@131.104.62.55) has joined #duraspace
[19:58] * keithg (~keith-noa@207.138.47.158) has joined #duraspace
[20:01] <PeterDietz> hi all
[20:01] <tdonohue> Hi all -- about time to get started. Just an FYI, elinstangeland is joining us from the DSpace Community Advisory Team (DCAT), previously known as DGOC group
[20:01] <mhwood> Howdy.
[20:02] <elinstangeland> Hello
[20:02] <tdonohue> We'll kick things off with the normal JIRA review process for first 15-20mins
[20:02] <robint> Hi Elin
[20:02] <tdonohue> Here's a search of recent JIRA issues: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-651+ORDER+BY+key+ASC We'll be starting at DS-651
[20:02] <tdonohue> DSpace Intermediate Metadataformat DIM - include handle or ID : https://jira.duraspace.org/browse/DS-651
[20:04] <grahamtriggs> evening
[20:04] <tdonohue> hmmm.. anyone understand what Claudia is asking for in DS-651? I thought we already do include the DSpace Handle in 'dc.identifier'?
[20:05] <tdonohue> I mean 'dc.identifier.uri' includes the Item Handle
[20:05] <robint> I think the reference to the handle is misleading.
[20:06] <elinstangeland> I read this to mean that not all metadata is included in the DIM, and she suggests that they should be?
[20:06] <robint> The other stuff she refers to is held in the Item table as she describes
[20:06] <elinstangeland> May be wrong though
[20:06] <grahamtriggs> it includes the handle formatted as a uri, and not the raw value. The raw value - plus all of the metadata that exists as columns in the item table would be useful to have
[20:07] <tdonohue> aha. Ok, now I understand. So, perhaps she's suggesting a separate metadata schema called "dim" (instead of just 'dc') which includes this extra info which doesn't easily fit into Dublin Core, persay?
[20:07] <elinstangeland> From my point of view it would make sense to keep this infor together at least
[20:08] <elinstangeland> infor = info
[20:08] <PeterDietz> I'm thinking its to have another section in http://demo.dspace.org/xmlui//metadata/handle/1842/207/mets.xml such as the meta-information (inArchive t/F)
[20:08] <robint> Or she just wants it exposed whenever DIM is generated
[20:08] <mhwood> Mark this "please explain further"?
[20:08] <tdonohue> sounds like we have ideas all over -- we need to get things narrowed down :)
[20:09] <tdonohue> mhwood -- yea, I'd agree, we need to come to a common understanding of what is needed, and then find a volunteer or two
[20:09] <tdonohue> DS-651 - Will ask Claudia to explain further, need more details. Others are also encouraged to add their feedback/ideas/comments
[20:09] <tdonohue> In essence of time, moving on..
[20:10] <grahamtriggs> I don't think it should be a metadata field encoding, as it has the potential to conflict with registered schemas, but adding an encoding of the non-registered field data on an item representation seems sensible, providing we have a good markup for it
[20:10] <tdonohue> MetadataExposure hides fields except for System Admins - this should extend to Community and Collection Admins : https://jira.duraspace.org/browse/DS-655
[20:10] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:10] * PeterDietz adds that determining if the current user is a collection admin is not as straight forward
[20:10] <mdiggory> HI everyone
[20:11] <tdonohue> hi mdiggory.. we're doing JIRA review, currently on: https://jira.duraspace.org/browse/DS-655
[20:11] <mdiggory> catching up
[20:11] <PeterDietz> super admin == isAdmin().. collection admin == Group.isMember(context, collection.getAdministrators().getID())
[20:12] <tdonohue> Anyone have thoughts on DS-655, or volunteer to look into this in more detail? It sounds like Bill Hays has a point, but I am not as familiar with this area of the code
[20:13] <mdiggory> What she is asking for is authorization on metadata fields
[20:13] <mdiggory> so that specific fields can be hidden from specific users
[20:13] <mdiggory> pubic vs administrator
[20:14] <tdonohue> PeterDietz: Doesn't the AuthorizeManager.isAdmin(context, DSpaceObject) method find a Community or Collection Admin?
[20:15] <mdiggory> PeterDietz: especially with the new delegation support
[20:15] <tdonohue> volunteers to investigate or add further comments to DS-655?
[20:16] <robint> tdonohue: I'll take it
[20:16] * hpottinger (80ce6c20@gateway/web/freenode/ip.128.206.108.32) has joined #duraspace
[20:17] <tdonohue> ok, assign DS-655 to robint for investigation. Will revisit later as necessary
[20:17] <tdonohue> we'll do one more..
[20:17] <mdiggory> TBH, theres already so much backwardness in the OAI implementation... I wouldn't be worried about efficiency losses due to actually attempting to authorize the content...
[20:17] <tdonohue> Provide a "nonAnon" attribute to XMLUI theme : https://jira.duraspace.org/browse/DS-658
[20:18] <mdiggory> hmm
[20:19] <mdiggory> viewing is part of the Items attached Resource Policies....
[20:19] <mdiggory> You would review the ResourcePolicies to see if the current EPerson had rights to view the item in the first place
[20:19] <tdonohue> right, mdiggory, but we don't have ResourcePolicies on metadata fields (which is what this is asking about)
[20:20] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[20:20] <mdiggory> thinking this can be restricted in the theming layer is probably not the best approach
[20:20] <tdonohue> in a way, this seems parallel to DS-655 -- seems to be about permissions on metadata fields
[20:20] <mhwood> Yes, like 655
[20:21] <tdonohue> mdiggory, i agree, not sure I like the patch's approach in DS-658. It shouldn't be in the Theme (as it also would need to work for JSPUI, OAI, etc)
[20:21] <mdiggory> Seems that we are in the process of inventing a richer ResourcePolicy capability
[20:21] <tdonohue> bingo :)
[20:21] <mhwood> Yes, putting access-control code in theme layer is not so good. Then we have to duplicate it in every other UI (treating e.g. PMH as a UI...).
[20:22] <mdiggory> This is something I banged my head on with the dspace2 work repeatedly, but never came to a complete conclusion on.
[20:23] <mdiggory> And it comes back to both (a) improving how Item manages updating metadata and (b) maing the ResourcePolicies be more granular
[20:23] <kshepherd> hi all
[20:23] <tdonohue> Ok, shall we link DS-658 as related to DS-655, and wait on robint to investigate DS-655 (to see where that starts to lead us?). Also, if anyone has ideas brewing, feel free to write up a proposal for how to deal with ResourcePolicies & Metadata
[20:23] <mhwood> Are metadata resource policies per-site, per-container, per-Item?
[20:24] <mdiggory> could be ;-)
[20:24] <tdonohue> mhwood -- good question :) could be any, but I'd think the most important initially would likely be per-site and per-container
[20:25] <mdiggory> well, we could take this discussion into dealing with policies attached to delault item read default bitstream read into consideration
[20:26] <mdiggory> thats what we are starting to refer to here... default_metadata_read policy
[20:26] <tdonohue> DS-658 -- Will link as related to DS-655 & suggest that this is part of a larger issue. Everyone is welcome to add further ideas/comments. We need to brainstorm & draft proposal for how to deal with permissions on specific metadata fields.
[20:26] <grahamtriggs> I think there is a more basic question to ask - it's not 'right' to implement such controls in the theme, so no shipped theme would implement making this decision. But could/should more information be exposed to the theme layer so that people could provide solutions within their local themes if necessary?
[20:26] <robint> I'm off to unassign DS-655 from myself... :)
[20:26] <tdonohue> robint: You didn't know what you were getting into, did you :)
[20:26] <robint> Doh!
[20:27] <mdiggory> grahamtriggs: I'd say no.
[20:27] <kshepherd> i'd say no too
[20:27] <mhwood> Make it one of those "call back into Cocoon" objects, so you can get the data if you want 'em but we don't inflate the DRI with stuff seldom used?
[20:28] <tdonohue> robint: I think if you just want to find a possible solution to DS-655 that's fine. Hopefully that solution or idea, can help us brainstorm out ways to extend it for other usages (and if not, then we'll create another JIRA issue to tackle the much larger problem of Metadata permissions)
[20:28] <mdiggory> This patch could be rewrittent to not alter Item
[20:28] <kshepherd> well, at least, not in a way that implies the theme is the place to be doing security/hiding metadata
[20:29] <mdiggory> nothing in the patch uses anything internal to the Item, I'm against adding convenience methods to the Item object unless they actually require access to the private contents of the Item object
[20:30] <tdonohue> mdiggory -- likely, he changed Item directly because there's already an Item.canEdit()
[20:31] <tdonohue> so, that's why the canView() was likely added there
[20:31] <mdiggory> Probably shouldn't be there as well
[20:31] <mhwood> Hmmm, one of the things private to any class should be detailed knowledge of how it works.
[20:31] <mdiggory> that has nothing to do with how it works, the ResourcePolicies are on it, not in it
[20:32] <mhwood> OK
[20:33] <tdonohue> Ok. Shall we stop there? If there are other comments/suggestions, feel free to add directly to DS-658 issue
[20:33] <tdonohue> Next Topic: Upcoming release schedules & a call for release coordinator(s)
[20:34] <tdonohue> First off, anyone interested in being either the 1.7.1 release coordinator or the 1.8.0 release coordinator? If so, you get an extra say in (a) what goes in them, and (b) what the schedule may look like :)
[20:35] <kshepherd> *tumbleweed*
[20:35] * tdonohue pauses to see if anyone takes the bait...
[20:35] <PeterDietz> I know the being bug-free is unprecedented, but if no grave bugs are discovered in 1.7, would be we be able to create 1.8?
[20:36] <PeterDietz> bug free, other than my sentence
[20:36] <mhwood> Bug-free 1.7 is not a prerequisite for starting 1.8, is it?
[20:37] <kshepherd> no, i think peter's just asking if 1.7.1 might be skipped altogether
[20:37] <PeterDietz> oops, I was thinking 1.7.1, exactly kshepherd
[20:37] * mdiggory thinks.... with great power comes great responsibility
[20:37] <tdonohue> no.. 1.8.0 can start immediately. The only rule right now is that new features go into 1.8.0. Bug fixes would go into 1.7.1 (and in turn 1.8.0)
[20:37] <tdonohue> kshepherd & PeterDietz. Sure, if there were no bugs, we could potentially skip over 1.7.1
[20:38] <kshepherd> personally, i think there are so many new features in 1.7 that it'd be nice to apply some polish for a 1.7.1 release, and get in any fixes, even if they aren't for *grave* bugs
[20:38] <mhwood> The problem is that "no bugs" is something you find out later. Infinitely later, in fact.
[20:38] <mdiggory> we would just identify that a 1..7.x branch would come from the 1.7.0 tag and that 1.8.0 work goes on in the trunk
[20:39] <tdonohue> 1.7.x branch already exists: http://scm.dspace.org/svn/repo/dspace/branches/dspace-1_7_x/
[20:39] <mdiggory> there you go...
[20:39] <kshepherd> :)
[20:40] <tdonohue> I'll also note that currently, in JIRA, we already have a small number of issues "tentatively scheduled" for 1.7.1: https://jira.duraspace.org/browse/DS/fixforversion/10353 (These are bugs that were reported in 1.6.2, but we actually didn't get around to completely fixing in 1.7.0, so they still exist there)
[20:40] <kshepherd> commit activity to that branch will probably determine how necessary a 1.7.1 release is
[20:40] <mdiggory> the big question should always be: "Is a change in trunk compatible enough with 1.7.0 to be considered an addition to the 1.7.x branch as well?"
[20:41] <mdiggory> JIRA issues should be reviewed and considered if they should go on the tunk and/or the branch
[20:42] <tdonohue> agreed, we should review these issues. But, considering our issue backlog, the easiest quick solution was to move all bugs fixes that were incomplete for 1.7.0 to be scheduled for 1.7.1
[20:42] <kshepherd> 1.6.1 was a very strict "bug fixes only" policy
[20:43] <mdiggory> if we are going to maintain a fixed release schedule, then what kshepherd stated is very very important
[20:43] <tdonohue> yes...to be clear, our current policy still is that 1.7.1 should have a strict "bug fix only" policy. If we wanted to change that, we'd have to vote on it
[20:43] <tdonohue> 1.8.0 = new features/improvements, 1.7.1 = bug fixes only
[20:44] <mhwood> If we have both lines, then 1.7.1 can come out whenever there are enough fixes, or enough criticality, to do so, while 1.8 chugs along on a fixed schedule.
[20:44] <kshepherd> mhwood: yep, i like that idea
[20:44] <tdonohue> exactly, mhwood. Sorry, I must've not been clear about this :)
[20:44] <tdonohue> 1.8.0 can start immediately. 1.7.1 will come out whenever.
[20:45] <tdonohue> That's why I was asking for *two* volunteers to be Release Coordinator of 1.7.1 and 1.8.0, respectively
[20:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Read error: Connection reset by peer)
[20:45] <PeterDietz> I can stick with 1.7.x monitoring the remnants of the to-do, and prod the rest of us to test/commit their issues. I'm not sure I want to touch maven still
[20:45] <mhwood> It's also attractive to separate potentially destabilizing new stuff (1.8) and fixing existing stuff (1.7.x)
[20:45] <tdonohue> again, my mistake -- I'm obviously not being as clear as I meant to be :)
[20:45] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) has joined #duraspace
[20:46] <tdonohue> PeterDietz -- the maven issues you struggled with before have been fixed, I assure you :) and if you had more issues, I know it well now (as does mdiggory)
[20:46] <kshepherd> a few people are still on holiday, a lot of us have just started back at work and are catching up in terms of dspace community stuff as well as office stuff
[20:46] <PeterDietz> I think I'm once bitten, twice shy
[20:47] <kshepherd> would it make sense to re-visit this next meeting? or are we running out of time?
[20:47] <tdonohue> So, PeterDietz, was that you volunteering to do the 1.7.1 Release Coordination (assuming we find the need to do 1.7.1)
[20:47] <PeterDietz> still on holiday, I think I had to resume work the business day after christmas, and new years :(
[20:48] * PeterDietz is volunteering to be 1.7.1 Release Coordinator
[20:48] <tdonohue> kshepherd: we can revisit if we have no volunteers. I'll also send a note for volunteers to dspace-commit after this mtg
[20:48] <tdonohue> thanks PeterDietz :)
[20:49] <tdonohue> Ok. Moving on (for now) to schedule.
[20:49] <PeterDietz> perhaps since 1.8dev is still a bit green, it can stay in the committer-lead release status until theres a front-runner for the project
[20:50] <tdonohue> based on last week's discussion, there was a lot of talk about potentially doing some "beta" releases, so that it would allow us all to get features out there earlier. The idea (which richard r proposed) was that after a beta release we could *change* features. So they would happen *before* a feature freeze.
[20:50] <tdonohue> I had posted a very tentative sample 9 month schedule here: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-01-12
[20:50] * John_____ (83bb423a@gateway/web/freenode/ip.131.187.66.58) has joined #duraspace
[20:51] <tdonohue> It's open to comments/suggestion/massive changes, etc. Again, this is just an idea
[20:51] <tdonohue> I chose 9months because that was the same time period between 1.6.0 and 1.7.0
[20:52] <tdonohue> thoughts? anyone like or hate this idea? Would we rather change our 9 month schedule to something different (12 months?)
[20:53] <kshepherd> i'm ok with 9 months. that's probably the min i'd vote for. also, it would be nice to avoid releasing close to the EOY holidays :)
[20:53] <tdonohue> (roughly -- this proposed timeline is almost identical to how 1.7.0 was scheduled. The only difference is that two "beta" releases were added to the beginning)
[20:53] <mhwood> Don't like or hate the schedule -- probably a good sign. Should not go longer without a specific reason?
[20:53] <grahamtriggs> As a general point, I don't particularly like 9 months as a regular thing - it cycles through different times of the year, which makes it a bit awkward. Realistically, I think I prefer 12 months, but we should adjust the actual date to something suitable (ie. we might want to go for Oct/Nov to give as a bit more time before the holidays)
[20:54] <mhwood> 6-month cycle, spring and fall?
[20:54] <kshepherd> grahamtriggs: i'd be ok with that too... i just wouldn't go as low as 6 months (too quick), 12 months seems to long for some, so i guess 9 months was a good compromise between those, two
[20:54] <tdonohue> we could do 6-month -- but, obviously the releases would be smaller (less new features)
[20:55] <mhwood> How many new features do we need for a release?
[20:55] <tdonohue> mhwood -- no minimum or maximum. It's really up to us. We just need to have a reason why people would want to upgrade
[20:55] <tdonohue> (or, alternatively, make it *dead simple* to upgrade)
[20:56] <tdonohue> i'm also open to the 12mos idea -- I'd agree though we may want to adjust so that it doesn't always conflict with the holidays (like 1.7)
[20:57] <grahamtriggs> 6 months seems a bit quick if we want to go through beta stages. It feels like you would want to do betas in say July, August, September before gearing up for an Oct/Nov release. If you were then to do six month cycle, you would be almost immediately back in betas - which isn't enough time unless there are people overlapping on developing for the next release
[20:57] <tdonohue> honestly, we could also do this release by release. We could say that 1.8 will be a 9mos release, and 1.9 (or whatever next) will be decided once we get to it
[20:57] <kshepherd> 12 months is good, we could stil plan to release RC1 after 9 months of that 12
[20:57] <mhwood> I don't mean to push for shorter cycles. I just have a vague feeling that longer ones don't provide enough pressure to get stuff done, somehow.
[20:57] <kshepherd> and the last 3 are testing, newer RC releases, etc.
[20:58] <kshepherd> mhwood: maybe the 6/9/12 month schedule needs to be broken down more, with 'phases' and deadlines that we actually have to keep ;)
[20:58] <kshepherd> easier said than done...
[20:58] <tdonohue> yea, hence the idea of "betas" being those various phases
[20:58] <tdonohue> :)
[20:59] <mhwood> Thinking a bit, scheduled betas would be equivalent to phases.
[20:59] <kshepherd> gotcha
[20:59] <kshepherd> (i'm on my first coffee of the day, please excuse my slowness ;P)
[21:00] <tdonohue> So, if we looked at the proposed 9month schedule, our first beta would be released in mid-May. Whatever is ready by then gets into the Beta release (and gets early eyes on it & early testing). Everything else goes into either Beta2 (by June) or in before Feature Freeze (July 22)
[21:00] <PeterDietz> so to reapply beta mentality to 1.7, beta1 could have gotten mirage and a handful of changes, beta 2 google scholar and other handful of changes, beta 3 could have gotten discovery
[21:00] <mhwood> And after September (final release) we go to a 12-month cycle? Feature release every fall?
[21:00] <tdonohue> so, in that way, my proposed schedule has 3 phases -- Beta1, Beta2, Feature Freeze -- before we go to RC1
[21:01] <robint> How much will a beta release demand of the release coordinator ?
[21:01] <tdonohue> beta releases would just mean you cut a release then. Whatever is "in", is "in", whatever is not, too bad :)
[21:02] <tdonohue> so, it wouldn't be very high demand. It'd just take the coordinator an 20-60mins to cut the release (and it'd be good practice on cutting releases)
[21:02] <robint> Understood, just that I worry that all these beta and RC releases will eat up a lot of the coordinators time
[21:02] <mhwood> And noting things which are visible but not quite ready.
[21:02] <robint> Ah ok.
[21:02] <kshepherd> it's important we document our new features as we go, so that they're well-described by the time beta is cut, and we don't shove it all on jeff
[21:03] <tdonohue> yep -- new features would have to be documented *as we go*. The coordinator would *not* be responsible for documenting anything in the beta releases
[21:04] <tdonohue> So, beta releases are good, cause you get your stuff out there earlier for early review (and can still change it before the final release), but you have to have your docs decently ready as well
[21:04] <PeterDietz> would there be a situation where something gets added to a beta, but then removed for the next beta / feature freeze?
[21:05] <tdonohue> I'll also note that we really need to reanalyze how we are doing Docs. It was a horrible 2 days for Jeff & I just before 1.7.0, trying to cleanup everything at the last minute. We need to rethink our processes
[21:06] <tdonohue> PeterDietz -- preferrably, no. But, "betas" are not guarranteed to have the same features as a final release. So, it could potentially happen if a feature was that "bad" (but hopefully we don't build such bad features :)
[21:06] <mhwood> Well, if I send up something un(der)-documented, I expect to be chastised for it.
[21:07] <hpottinger> the nice thing about betas is, if a new feature isn't sufficiently documented, your users won't be shy about letting you know. :-)
[21:08] <mhwood> Perhaps. I often find that users are more shy than I'd like, at any stage of development.
[21:08] <tdonohue> hpottinger: very true :) it also gives us more opportunities to chastise those who aren't giving proper docs (as mhwood suggests)
[21:09] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Quit: Page closed)
[21:09] <tdonohue> mhwood -- even though users may be shy, it also gets the developers to actually look at your feature & respond at an earlier stage in the process (rather than everything going into Trunk at the same time in the last week before the "freeze")
[21:09] * tdonohue sorry we're running well over here
[21:10] <kshepherd> mdiggory: left a comment for you in #dspace
[21:10] <grahamtriggs> tdonohue: It might be a bit too idealistic to expect to significantly change the effort involved there, but it needs to be better catered for (ie. starting the 'make sure everything is clean' task earlier, and having more people involved/responsive)
[21:11] <tdonohue> grahamtriggs: right -- the problem with the 1.7.0 process was no one was "assigned" that task of 'make sure everything is clean', and no one took it up until the last week when we all suddenly realized where the docs really stood
[21:12] <tdonohue> (hence -- we need to be clearer about how we want to manage docs going further, and who is "in charge" of that area)
[21:13] <kshepherd> well, the wiki thing is good
[21:13] <kshepherd> fwiw
[21:13] <tdonohue> Ok -- any final thoughts here? I'm going to send this tentative 9mos schedule to dspace-commit. Please comment on it further, or propose an alternative schedule if you have one.
[21:14] <mhwood> "in charge" = "stuck with the job of herding programmers".
[21:14] <tdonohue> kshepherd - yea, I think the wiki step was good. We just need to clean out the other problem areas, and find a "team" (preferably) who is willing to manage the wiki docs more closely)
[21:14] <kshepherd> tdonohue: maybe include 12 months as an alternative? just to avoid the problem graham mentioned of ever-changing release dates?
[21:14] <tdonohue> "in charge" = we need a team -- Jeff cannot be expected to do this alone, as he hasn't the time
[21:15] <kshepherd> yep, he's doing an awesome job... but that doesn't mean we can be lazy ;P
[21:15] <tdonohue> I'd be against a 12mos right now though -- it'd put us back in Dec 2011? I thought we wanted to avoid the holidays?
[21:15] <kshepherd> right, we wouldn't be able to *start* that schedule now
[21:15] <mhwood> 9mo. this time, then 12?
[21:15] <kshepherd> i see.. that makes more sense, yeah
[21:15] <tdonohue> My thought was 1.8 = 9mos (or 10), and then move to 12mos
[21:15] <tdonohue> exactly, mhwood
[21:16] <grahamtriggs> October, and 12 months thereafter?
[21:16] <tdonohue> Ok, I'll draft up a tentative Oct schedule too. We can vote on it in dspace-commit list.
[21:17] <tdonohue> With that -- I'll go ahead and close things up, as we are way over time (sorry about that, but this was good discussion, I think). I'll stick around here if anyone has anything else to talk about
[21:17] * tdonohue consider meeting closed, but you are welcome to stick around and still chat
[21:18] <kshepherd> see #dspace if you want to see a screenshot of something nifty i did to my item view template with JSONSolrSearcher :)
[21:22] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:23] * hpottinger (80ce6c20@gateway/web/freenode/ip.128.206.108.32) Quit (Quit: Page closed)
[21:26] * elinstangeland (56097ad4@gateway/web/freenode/ip.86.9.122.212) Quit (Quit: Page closed)
[21:31] * John_____ (83bb423a@gateway/web/freenode/ip.131.187.66.58) Quit (Quit: Page closed)
[22:03] * keithg (~keith-noa@207.138.47.158) has left #duraspace
[22:08] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) Quit (Read error: Connection reset by peer)
[22:11] * ksclarke (~kevin@airport-grey.nescent.org) Quit (Quit: Leaving.)
[23:11] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
[23:54] * bradmc (~bradmc@207-172-69-79.c3-0.smr-ubr3.sbo-smr.ma.static.cable.rcn.com) Quit (Quit: bradmc)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.