Timestamps are in GMT/BST.
[16:37] [freenode-connect VERSION]
[16:37] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[16:37] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[16:37] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[16:37] <mdiggory> perhaps there should be authorization in front of the uri
[16:37] <kshepherd> but i agree it's a part of a much larger issue
[16:37] <stuartlewis> So maybe skip it for 1.6, and add it as a central issue for whatever comes after the 1.6 branch?
[16:37] <mdiggory> I'd say if kshepherd sees a solution... feel free to approach it
[16:37] <mhwood> Agree, I don't think there's time for 1.6.
[16:37] <kshepherd> i'm guessing that's how the voting will go, yeah ;) just wanted to get some feedback on the whole "open access vs OPEN access" thing :) thanks
[16:38] <bradmc> Yes, it seems late in the day to get a good solution for 1.6, but if Kim comes up with a miracle we can revisit.
[16:38] * cwilper (i=4a2c9b5a@gateway/web/freenode/x-naaqbxpuxueqqxxu) has joined #duraspace
[16:38] <mdiggory> authorization in front of /metadata/handle/xxxxxx/mets.xml shouldn't be a difficultly
[16:38] <bradmc> cwilper: Thanks for log bot fix.
[16:39] <mhwood> Hmmm, well, if this aspect can be fixed now, great, but the larger question is going to take some time. If we have access controls at all they should be consistent (whatever that means) across all access modes.
[16:39] <cwilper> np, will robustify it soon
[16:39] <mdiggory> adjust teh sitemap to wrap the authorization matcher around the metadata match
[16:39] * bradmc (firstname.lastname@example.org) Quit (Read error: 104 (Connection reset by peer))
[16:40] * grahamtriggs (email@example.com) has joined #duraspace
[16:40] <kshepherd> yep, that's a quick specific solution for that particular one
[16:42] <kshepherd> brad's gone.. who's backup mod? ;)
[16:42] <grahamtriggs> no-one. anarchy... ANARCHY!!!!
[16:42] * kshepherd starts looting
[16:42] <bollini> sorry to go back to specific jira issue but I need to prioritize them so that I can fix the most relevant in time for 1.6
[16:43] <bollini> http://jira.dspace.org/jira/browse/DS-267 who agree with Larry comments?
[16:43] <grahamtriggs> kshepherd: wouldn't bother. There's only a bot in the corner, and by the looks of it, it's a bit broken
[16:44] <mdiggory> HandleAuthorizedMatcher... might need minor surgery to support /metadata/handle uri
[16:44] <rrodgers> bollini: I still feel this is not the best approach to influencing policy by submitter
[16:45] <jat_ysu> Admins really don't want submitters changing a policy on the fly.
[16:45] <bollini> rrodgers: I could agree... but this is mainly a fix for withdrawn item
[16:46] <mdiggory> I agree
[16:46] <mdiggory> with jat_ysu
[16:46] <bollini> :-(
[16:46] <rrodgers> bollini: as for withdrawal, I agree it's not perfect, but is this a big problem?
[16:47] <mdiggory> but... we actually do have a case where we want the user to select from several permissions profiles...
[16:47] <mdiggory> during the submission process
[16:47] <mdiggory> we are not using DEFAULT_XXXX for this however
[16:47] <jat_ysu> Okay, in that case you need to be able to insulate users from having that option as a default option. Perhaps only certain authorized users.
[16:47] <kshepherd> bah, no solr books on our safari bookshelf :(
[16:47] <rrodgers> yes, I think allowing entry of instructions or preferences is fine
[16:47] * bradmc (firstname.lastname@example.org) has joined #duraspace
[16:48] <mdiggory> kshepherd: I'll send you a url...
[16:48] <grahamtriggs> jat_ysu: but when the submitter is an admin.... besides, if you want embargoes, then you are ceding (a certain amount of) policy control to the submitter... oh, the tangled web we weave...
[16:48] <bollini> rrodgers: no really... (withdrawn)
[16:48] <jat_ysu> User A is able to submit and make changes to collection 45, but User B can only submit to Collection 45, but not change.
[16:49] <mdiggory> grahamtriggs: sure.. you do, but its controlled
[16:49] <jat_ysu> Well, I'm the only admin who submits, but we have 45 other submitters who are not admins.
[16:49] <mdiggory> I just don't think those "Actions" should be bastardized in that way... we need better controls than that...
[16:49] <bollini> jat_ysu: this is more a question about UI... the DS-267 give us a place where store this data
[16:50] <mdiggory> permissions templates
[16:50] <grahamtriggs> is there really any reason why we don't just assign policies at the point of creation - and then have whatever *controlled* means of affecting them that we choose?
[16:50] <rrodgers> bollini: also look at the Embargo as a model, you can enter metadata that the system interprets as policy
[16:51] <rrodgers> in a controlled way
[16:51] <mdiggory> rrodgers: is the policy applied when the metadata is entered... or on archiving of the item?
[16:51] <bollini> collection A: open access, embargo (starting date), restricted access to a specific group - collection B: no option all open access - collection C: no option all restricted, etc.
[16:51] <rrodgers> on installation - before that the policy means nothing
[16:52] <mdiggory> k
[16:52] <bollini> using metadata we have issues to manage policy on a bitstream basis
[16:52] <mdiggory> oh how InstallItem needs plugability...
[16:52] <jat_ysu> Okay, I see where you are going....there are already "pre-determined" policy choices for the submitter?
[16:53] <rrodgers> mdiggory: Embargo does just that
[16:53] <mdiggory> :-)
[16:53] <mdiggory> commit IT!
[16:53] <rrodgers> ;)
[16:53] <jat_ysu> bollini:?
[16:53] <bollini> jat_ysu: yes
[16:53] <jat_ysu> And configurable?
[16:54] <jat_ysu> If so, I endourse your proposal.
[16:54] <bollini> I'm working on...
[16:54] <jat_ysu> It still leaves control in the hands of the admins, and the submitter can just make lousy choices.
[16:54] <jat_ysu> can=cannot
[16:54] <mdiggory> rrodgers: you have the force... use it wisely ;-)
[16:55] <rrodgers> mdiggory: cool
[16:55] <jat_ysu> <== wants to use Sith Lightenting.... ;-)
[16:55] <bollini> just to be more clear ds-267 is not against the rodgers embargo
[16:56] <bollini> I have asked for comments because (as Larry as underlined) it makes the policy system more "confusing"
[16:57] <jat_ysu> Well, it does, but a good understanding/grasp of what this option gives use should make it less of a problem.
[16:57] <jat_ysu> I think in general the whole Policy issue is undaunting for the neophyte admin with dspace.
[16:58] <rrodgers> bollini: I have to think about lcs proposal a bit more
[16:59] <bradmc> Well, I came back from my alternate reality (should have known you guys wouldn't really go that silent), but I have a hard stop on these 20:00 GMT Weds. As per usual, please continue as you see fit, preferably with a minimal amount of looting, and no fires, lightning or otherwise.
[16:59] <bollini> well... I will wait for your comments, if you want I will go ahead to develop the UI with configurable choices for the submitter
[17:00] <jat_ysu> IMHO, it might be worth seeing it in action/testing.
[17:01] <bollini> now, I need to prioritize my tasks for 1.6 (to be able to meet the deadlines)
[17:01] <bollini> http://jira.dspace.org/jira/browse/DS-236
[17:01] <bollini> http://jira.dspace.org/jira/browse/DS-267
[17:01] <bollini> http://jira.dspace.org/jira/browse/DS-270
[17:01] <bollini> please give me your opinions
[17:02] <rrodgers> Id say start with 270, which is your work, yes?
[17:03] <bollini> yes it is an abstraction
[17:03] <stuartlewis> Yes, 270
[17:03] <rrodgers> there may be assistance for 236 in time
[17:03] <stuartlewis> Will 236 be ready for 1.6?
[17:03] <bollini> 236 is a big task
[17:03] <stuartlewis> (e.g. two week deadline)
[17:04] <bollini> all the code xmlui/jspui/postgres/oracle is in the sandbox
[17:04] <stuartlewis> Is it all tested and working, or is there lots left to do?
[17:05] <bollini> well... I have tested a lot the jspui/postgres implementation but on a 1.5.0 installation
[17:06] <bollini> the 1.6 porting has been make on the fly and I have done only a fast run on it (all seems to work)
[17:07] <bollini> there is also a lot of work to do on the i18n
[17:10] <mhwood> We need to find some "language wranglers" who can drive i18n development and maintenance. The skill set is different from most coding.
[17:10] <stuartlewis> Would you feel more comfortable leaving it for after 1.6?
[17:11] <bollini> most depend on the Larry availability
[17:12] <bollini> I think that it will be really a big new feature and most people will love it
[17:13] <bollini> but if I have to address the other two jira issues I have only marginal time for it (so only assistance not drive)
[17:14] <stuartlewis> Maybe we should see how time goes over the next two weeks, and at the end of the month make the final call for what will, and what will not, be in 1.6?
[17:14] <bollini> fine
[17:14] <mhwood> Yes
[17:15] <stuartlewis> Would be great if all these big features could get in, but if we don't make a final call at some point, we'll never get the release out.
[17:16] <mhwood> Must go, thanks everyone!
[17:17] <stuartlewis> Same here. Time to formally wrap up, or anything else to talk about?
[17:17] <bollini> my primary concern is TESTING we need to make wide testing before release
[17:17] * mhwood (email@example.com) has left #duraspace
[17:18] <stuartlewis> Yes. Ideally I'd like to see us freeze at the end of the month, two weeks of testing / getting the build sorted etc, then a release candidate + LiveCD (for testing) at the DSUG in mid-October
[17:18] * jat_ysu (firstname.lastname@example.org) Quit ("Leaving")
[17:19] <bollini> ok, see what happen in the next weeks...
[17:19] <rrodgers> Must also go - but I'd say there are a lot of goodies in 1.6 already, so we should err on the side of testing/stability
[17:20] <kshepherd> indeed
[17:20] * rrodgers (email@example.com) Quit ()
[17:21] <stuartlewis> Maybe leads us to a 1.7 in Spring 2010? :)
[17:22] <kshepherd> hmm, my current contract won't have long to go by then
[17:22] <kshepherd> how time flies
[17:22] <kshepherd> stuartlewis: in t-shirt + shorts yet?
[17:23] <kshepherd> spring is definitely here in Hamilton
[17:23] <stuartlewis> I've been in t-shirt and shorts all winter (until I get to work, then have to change into something more respectable!). When summer really hits, I'll have to invest in some smarter shorts.
[17:25] <bollini> bye all - thanks!
[17:25] <stuartlewis> Bye Andrea, thanks for being here.
[17:25] * bollini (firstname.lastname@example.org) Quit ("ChatZilla 0.9.85 [Firefox 3.0.14/2009082707]")
[17:28] <kshepherd> heh, you're tougher than me, i've only just started
[17:28] <kshepherd> cheers all
[17:30] * ksclarke (email@example.com) Quit ("Leaving.")
[17:37] <stuartlewis> I cycle to work, so thats my excuse for shorts.
[18:01] * cwilper (i=4a2c9b5a@gateway/web/freenode/x-naaqbxpuxueqqxxu) Quit ("Page closed")
[18:03] * grahamtriggs (firstname.lastname@example.org) Quit ()
[18:14] * michaeldb (n=michaeld@CPE002436a25b34-CM000a739b087e.cpe.net.cable.rogers.com) Quit ()
[19:10] * mdiggory (email@example.com) Quit (Read error: 145 (Connection timed out))
[19:20] * mdiggory (firstname.lastname@example.org) has joined #duraspace
[19:32] * mdiggory (email@example.com) has left #duraspace
[19:34] * ksclarke (firstname.lastname@example.org) has joined #duraspace
[21:32] * ksclarke (email@example.com) Quit ("Leaving.")
[21:36] * ksclarke (firstname.lastname@example.org) has joined #duraspace
[21:54] * cwilper (i=4a2c9b5a@gateway/web/freenode/x-lklmqfqpubfjlqdq) has joined #duraspace
[21:56] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[21:56] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[21:56] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[21:56] [freenode-connect VERSION]
[22:09] * DuraLogBot (n=PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[22:09] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[22:09] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[22:10] [freenode-connect VERSION]
[22:28] * cwilper (i=4a2c9b5a@gateway/web/freenode/x-lklmqfqpubfjlqdq) Quit ("Page closed")
[23:30] * awoods (email@example.com) Quit (Read error: 110 (Connection timed out))
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.