Timestamps are in GMT/BST.
[2:05] -kloeri- [Global Notice] Hi all. We're experiencing some technical problems and as a side-effect of that services email is currently down. This means that registering nicks and sending password reset emails won't currently work. The mails will be queued up but it's unknown when they'll be delivered. Thank you for using freenode.
[6:49] -card.freenode.net- *** Looking up your hostname...
[6:49] -card.freenode.net- *** Checking Ident
[6:49] -card.freenode.net- *** Found your hostname
[6:49] -card.freenode.net- *** No Ident response
[6:49] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:49] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:49] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:52] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:54] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[14:46] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) has joined #duraspace
[14:46] * eddies (~eddies@cm18.epsilon183.maxonline.com.sg) Quit (Changing host)
[14:46] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[19:27] <tdonohue> interesting post on GitHub Blog that describes a few different ways in which they use Pull Requests (including using them as a way to just get feedback on work in progress or an idea): https://github.com/blog/1124-how-we-use-pull-requests-to-build-github
[19:27] <kompewter> [ How we use Pull Requests to build GitHub ยท GitHub ] - https://github.com/blog/1124-how-we-use-pull-requests-to-build-github
[19:40] * sands (~sandsfish@18.189.87.190) has joined #duraspace
[19:50] * ryscher (98033b4c@gateway/web/freenode/ip.152.3.59.76) has joined #duraspace
[19:52] <tdonohue> Hi all, reminder that at the top of the hour we have our weekly DSpace Developers meeting here : https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-05-02
[19:52] <kompewter> [ DevMtg 2012-05-02 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-05-02
[19:53] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:57] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:58] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:00] <tdonohue> Hi all, it's time for our weekly DSpace Developers Mtg. Today's agenda is up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-05-02
[20:00] <kompewter> [ DevMtg 2012-05-02 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-05-02
[20:00] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) has joined #duraspace
[20:00] <tdonohue> we'll get started as normal with some JIRA reviews
[20:00] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1006+ORDER+BY+key+ASC
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-1006 ] - [#DS-1006] authorizations via SpecialGroups methods are not properly created if an existing ePerson is found - DuraSpace JIRA
[20:00] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-1006+ORDER+BY+key+ASC
[20:00] <tdonohue> beginning with DS-1006
[20:00] <kompewter> [ https://jira.duraspace.org/browse/DS-1006 ] - [#DS-1006] authorizations via SpecialGroups methods are not properly created if an existing ePerson is found - DuraSpace JIRA
[20:02] <tdonohue> Oh, this is one of those several related issues in AuthN/AuthZ that hpottinger has noted. I'm now forgetting what the latest status of these is...
[20:03] <hpottinger> right, this was the other ticket I created as a result of DS-994
[20:03] <kompewter> [ https://jira.duraspace.org/browse/DS-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:03] <PeterDie_> I'm not an auth expert, but is one of the problems here with dspace groups?
[20:04] <PeterDie_> i.e. i create a PasswordAuth user, get essentially no group powers
[20:04] <PeterDie_> but one who creates a ShibUser gets my-campus-shib-group
[20:04] <PeterDie_> when the user tries to log in as a shib-user they don't have that group?
[20:05] <hpottinger> other related issues are potentially in the review today: DS-1007 and DS-1088
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1007 ] - [#DS-1007] AuthenticationManager.canSelfRegister is problematic with stacked authentication modules - DuraSpace JIRA
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1088 ] - [#DS-1088] AuthenticationManager.allowSetPassword is problematic with stacked authentication modules - DuraSpace JIRA
[20:06] <sands> is this ticket referring to groups that are dynamically added upon authentication, or groups that are tacked on to the EPerson upon self-registration?
[20:07] <hpottinger> dynamically added upon authentication, sands
[20:07] * mdiggory (~mdiggory@ip72-199-216-7.sd.sd.cox.net) has joined #duraspace
[20:08] <hpottinger> Do any group memberships ever get created automatically after self-registration?
[20:08] <mhwood> I hadn't thought so.
[20:08] <tdonohue> not to my knowledge. The 'getSpecialGroups' is used for the dynamically added groups.
[20:09] <tdonohue> (though admittedly, I'm the most hazy on the ShibAuth -- haven't ever used that one)
[20:09] <sands> my understanding was that all getSpecialGroups methods (from each method in the stack) were run, additively, so i'm not completely clear on how some are being prevented.
[20:11] <hpottinger> PeterDie_ you're describing the reason I attempted ds-994 and submitted ds-1006, ds-1007, and later ds-1008, when you say "i.e. i create a PasswordAuth user, get essentially no group powers"
[20:11] <kompewter> [ https://jira.duraspace.org/browse/ds-994 ] - [#DS-994] Add allow/deny rules for self-registration in the simple password authentication module - DuraSpace JIRA
[20:11] <kompewter> [ https://jira.duraspace.org/browse/ds-1006 ] - [#DS-1006] authorizations via SpecialGroups methods are not properly created if an existing ePerson is found - DuraSpace JIRA
[20:11] <kompewter> [ https://jira.duraspace.org/browse/ds-1007 ] - [#DS-1007] AuthenticationManager.canSelfRegister is problematic with stacked authentication modules - DuraSpace JIRA
[20:11] <kompewter> [ https://jira.duraspace.org/browse/ds-1008 ] - [#DS-1008] Solr Statistics markRobotsByIP can mark too many IP addresses, including IP's not on the IP list - DuraSpace JIRA
[20:11] <mdiggory> Sounds like it would be good if someone expanded on the JUnit tests in this area to make sure we know what behavior is expected out of the api
[20:11] <tdonohue> So, what is the next step here? Do we need to take a step back and re-look at Stackable Auth? Perhaps start up a wiki page to detail how we *expect* things to work and how they actually work?
[20:12] <mdiggory> yes, I agree.
[20:12] <mhwood> We talked about this before, and I think there was some thought that stackable authn needs review.
[20:12] <hpottinger> s/1008/1088/g
[20:12] <kompewter> hpottinger meant to say: PeterDie_ you're describing the reason I attempted ds-994 and submitted ds-1006, ds-1007, and later ds-1088, when you say "i.e. i create a PasswordAuth user, get essentially no group powers"
[20:13] <mhwood> IIRC there is confusion between authn and authz, and the tangle seems to be contributing to this problem.
[20:13] <hpottinger> mhwod, that's my recollection as well
[20:13] <sands> mhwood correct
[20:13] <mdiggory> one should be able to log in via password (or Shib, or CAS) and still have IPAuthen give additional rights if you are on campus.
[20:13] * hpottinger curses his lazy fingers
[20:14] <mhwood> OTOH if you log in via Shib it shouldn't try to do stuff through CAS. I guess.
[20:15] <mhwood> Maybe there is additional confusion in the notion of "implicit" methods.
[20:16] <tdonohue> so, I'm still curious on next steps. I agree there's a lot of confusion here, and I also wonder if we are even all on the same page (admittedly, I understand Ds-1007, but not Ds-1006). Would it be beneficial to start writing this up on the wiki (or somewhere else)
[20:16] <mdiggory> well, I'm not going to say that Shib users shouldn't get special groups from the CAS authenticator
[20:17] <tdonohue> just to flesh out all the scenarios a bit better, and make sure we all understand the problems
[20:17] <mdiggory> but I am going to say that IP, x509, are originally designed to be implicit
[20:18] <mhwood> See, right there we have both authn and authz going on. We need to work out how each works separately.
[20:18] <hpottinger> Not sure if we're ready for architecture discussion, but, I've been tinkering with Fedora Commons and Islandora lately, and they are using JAAS for AuthN and AuthZ...
[20:18] <mdiggory> and that thats a bit of a weird concept, Authentication of a user is based on specific criteria (username/password, IP, x509 cert) what should happen if multiple criteria are matched?
[20:19] <mhwood> Authentication must be done by one method. Authorization can be additive.
[20:20] <mhwood> Authentication only returns yes/no.
[20:20] <mdiggory> and should that be explicitly defined or bound up in the ordering of authentication methods in the stack?
[20:20] <sands> Yes, this area seems to be a squeaky wheel for some potential redesign.
[20:20] <mhwood> Addition is commutative.
[20:21] <sands> i think mdiggory was talking about authn
[20:21] <tdonohue> so, the other option could be to discuss this in a separate "special topics" meeting (via Skype), perhaps after we start to nail down 3.0 a bit better
[20:21] <sands> tdonohue: +1
[20:21] <mhwood> Authn method is chosen by the user.
[20:21] <mdiggory> +1
[20:21] <hpottinger> tdonohue: +1
[20:21] <mhwood> Yes, needs more time than is available in JIRA review.
[20:22] <tdonohue> ok, with that, I'm going to move us along. :) We'll table AuthN/AuthZ discussion for now, but I'll add a note that we likely need a "special topic" meeting after 3.0 is nailed down
[20:23] <tdonohue> we'll just stop the JIRA review there. Essentially we touched on (briefly) Ds-1006 and Ds-1007
[20:23] <tdonohue> both of which we will obviously be revisiting
[20:24] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:24] <tdonohue> next up. I just had an observation to mention in regards to Listserv Activity. I cannot help but notice that on dspace-devel & dspace-tech, most of the questions are being answered by helix84 (and thanks to helix84!)
[20:24] <tdonohue> I'm just wondering "out loud" if there's anything else we all can be doing to "chip in"?
[20:25] <tdonohue> I don't have a specific answer here -- just an observation. But, I do welcome comments/suggestions, if anyone has them
[20:25] <hpottinger> helix84 is pretty quick on the draw (which is appreciated, very very much)
[20:25] <mhwood> Most of the recent questions have been in areas where I felt that someone more knowledgable than I would soon chime in.
[20:25] <tdonohue> yea, that could be a part of it. helix84 is very quick to respond :)
[20:26] <tdonohue> I just didn't want it to start to "appear" as though the only support person is helix84 ;) Obviously that's not the case, though helix84 has been doing an amazing job at it
[20:26] <mdiggory> I think the challenge is that with the level of activity, its not possible to monitor and review everything in the dspace lists.
[20:27] <mdiggory> perhaps, if there was someone who might ping others in the group when a topic might be right for them to respond to
[20:27] <hpottinger> maybe we can make it a game, see if we can beat helix84 :-)
[20:27] <tdonohue> haha ;) nice.
[20:28] <richardrodgers> I think we should mostly remain laissez faire, but remember to thank active posters...
[20:28] <tdonohue> yea, I don't know how we could ever get more "organized" (the idea of pinging people is nice, but no one has time for that either). It's just more that I wanted to bring this to the forefront of everyone's mind
[20:29] <tdonohue> and I definitely encourage folks to try and beat helix84!
[20:29] <mdiggory> I will just say, I can't currently read the list on a daily basis, but I welcome nudges and pokes if someone thinks a topic is something I might have a good answer for.
[20:30] <tdonohue> though if helix84 is reading this, he definitely is the lead candidate for the 2012 award for the "most awesome support person" (not sure what the prize is yet)
[20:31] <hpottinger> drinks in Edinburgh, for sure
[20:32] <tdonohue> In any case, just hoping to see some more competition for that award :) We'll move along now though...more topics to touch upon
[20:32] <mdiggory> I have a couple
[20:32] <mdiggory> We now have two funded community development activities ongoing that are targeting new features for DSpace 3.0
[20:33] <mdiggory> The first was presented and a dialog opened in the last DCAT group
[20:33] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support
[20:33] <kompewter> [ Advanced Embargo Support - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support
[20:33] <PeterDie_> is this some type of not-GSOC, but otherwise Rent-A-Coder work?
[20:33] <mdiggory> This project is a partnership with UMICH and @Mire
[20:34] <tdonohue> mdiggory -- sounds like this may be in line with the next topic on the agenda, which was to talk 3.0 anyways (and look to schedule a "3.0 Planning" Special Topics Meeting)
[20:34] <mdiggory> to bring features of IDEALS and Deep Blue Bitstream Level embargo Support into DSpace 3.0
[20:34] <mdiggory> I can shift it to after your intro if you like
[20:35] <mdiggory> take the lead
[20:36] <tdonohue> Ok. my 3.0 intro is brief. Essentially, I just want to get a 3.0 Planning meeting scheduled sometime in the next few weeks. Either May 9 (next Weds) or May 16, and it'd be the same time as this meeting, but would be via Skype.
[20:36] <tdonohue> So, if anyone has strong opinions on the date, speak now. Otherwise, I'll just schedule it and send you all an email on it.
[20:36] <tdonohue> :)
[20:37] <mdiggory> either seems ok for me at the moment.
[20:37] <hpottinger> same time as this meeting: check; Skype: check, but my Skype mojo has been lacking lately
[20:38] <tdonohue> ok. hearing no strong opinions, I'll just get it on our schedule & email dspace-commit & dspace-devel with final details. It'll essentially be a similar Skype setup to what we used for the "Summit" (though obviously this will just be a single hour meeting)
[20:38] <sands> 9th would be better for me, in case there's a leaning one way or the other.
[20:39] <tdonohue> ok. 9th has a slight lead then. In any case, ping me if you have a strong opinion. We can move on to other 3.0 updates now -- take the floor, mdiggory
[20:39] <KevinVdV> I side with sands 9th would be better for me but I can also participate on the 16th
[20:39] <hpottinger> likewise, 9th is better for me
[20:39] <richardrodgers> can do either
[20:40] <tdonohue> sounds like it will be the 9th @ 20:00UTC. I'll send out an email with the final details on how you connect via Skype, etc.
[20:40] <sands> thanks for setting that up tdonohue.
[20:41] <tdonohue> mdiggory -- did you have more you specifically wanted to touch on for 3.0?
[20:41] <tdonohue> or were you just wanting to "make us aware" of that Advanced Embargo page & the discussion?
[20:42] <mdiggory> For 3.0 We have a number of projects that we will be detailing in the near future
[20:42] <mdiggory> these are more internal projects for @mire contribution.
[20:42] <mdiggory> I'll report on those later.
[20:43] <mdiggory> What I want to report on now is under a category of activity that we are calling "@mire client contributions"
[20:43] <tdonohue> would it be possible to send out some basic details to all of us before the 3.0 Skype meeting next week (9th)? I'd just like to encourage *all of us* to try and get our ideas out there before the Skype meeting (that way we can try to make that Skype meeting as productive as possible)
[20:43] <mdiggory> There are two specific projects, Bitstream Level Embargo and Item Level Versioning
[20:44] <mdiggory> Both these project differ from average @mire client projects in that we are exposing the requirements gathering to the community
[20:45] <tdonohue> cool -- sounds like a good idea :)
[20:45] <mdiggory> This style of activity originated in our work with ryscher and the Dryad project. Where requirements that everything be open source were specified. They differ in that now, in these two cases, the overall process is exposed to the community
[20:46] <PeterDie_> which should perhaps with greater overall adoption by the community... we all had an opportunity to weigh in
[20:46] <mdiggory> For the UMICH Embargo activites we presented the above wiki page deatailing the business and technical requirements for Bitstream level embargo for DCAT review
[20:46] <PeterDie_> kompewter: translate my previous statement into english
[20:47] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support
[20:47] <kompewter> [ Advanced Embargo Support - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Advanced+Embargo+Support
[20:48] <mdiggory> Yes, PeterDie_ the intent is that there is an opportunity to make sure that the general business goals and the technical proposal of a solution are acceptable by the committers before we expend the resource in creating the solution
[20:48] <mdiggory> As such we invite you to please review the proposal and comment on the requirements
[20:48] * ryscher (98033b4c@gateway/web/freenode/ip.152.3.59.76) Quit (Ping timeout: 245 seconds)
[20:49] <tdonohue> yea, I like the model for those projects. It's also a great way to loop in both DCAT & committers earlier on (when code/design can still be changed easily, etc).
[20:49] <tdonohue> sounds great. I agree it'd be good to have everyone do a quick review & comment
[20:50] * ryscher (98033b4c@gateway/web/freenode/ip.152.3.59.76) has joined #duraspace
[20:50] <mdiggory> The second project is between Woods Hole / Marine Biology Laboratory, Dryad and @mire
[20:50] <mdiggory> https://wiki.duraspace.org/display/DSPACE/Item+Versioning+Support
[20:50] <kompewter> [ Item Versioning Support - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Item+Versioning+Support
[20:51] <mdiggory> The objective of this project is to take the work done on Item Level Versioning that was put into place for Dryad contribute it to DSpace and implement further support for it in DSpace Applications
[20:51] <mdiggory> those applications being SWORD, LNI, ItemImport/Export, AIP Backup/Restore and so on
[20:52] <mdiggory> It also introduces support for alternate identification systems like DOI
[20:52] <mhwood> Yay!
[20:53] <mdiggory> The above wiki page is under heavy editing as I consolidate and clarify the work done in Dryad Item Level Versioning and bring forward the final implementation strategy that was taken with that codebase
[20:53] <tdonohue> yep, very cool stuff.
[20:55] <mdiggory> In both cases, there are technical work that alters the DSpace API / Data Model and introduces new database tables, as such getting feedback early is critical as these choice impact the rest of the development activity to bring them into dspace
[20:56] <aschweer> I wonder if we can introduce some sort of process for these initiatives to capture business requirements from a broader community base
[20:57] <aschweer> (I don't have any suggestions -- I just noticed that the embargo wiki page is already quite unwieldy, and in some parts very technical, which might put off some people who'd otherwise give useful input)
[20:58] <tdonohue> yea, I agree that both wiki pages are getting a bit unwieldy -- might even be helpful to split out into multiple wiki pages: business requirements, "user stories", tech details, etc.
[20:58] <aschweer> tdonohue +1
[20:58] <mdiggory> aschweer: the DCAT presentation and your feedback on that page were most beneficial to our refinement process. They brought up important questions concerning how embargo should be supported
[20:58] <aschweer> thanks mdiggory
[20:59] <mdiggory> the challenge was that in splitting, its also "obscuring"
[20:59] <tdonohue> yea, I think DCAT is a great way to get that broader community input (just adding a +1 to what mdiggory mentioned)
[20:59] <aschweer> yeah but once you start talking about database tables, you lose the less technically inclined. which is bad especially when there is more non-technical stuff further down the page.
[21:00] <tdonohue> mdiggory -- not really, as long as you interlink the pages as needed. It's just as obscuring to have to scroll up/down a large page to look at business requirements and then jump down to tech specs
[21:00] <ryscher> +1 to move all non-technical stuff to the top
[21:00] <mdiggory> thats why its important to be reorganizing the pages and make sure we have business reqs and overview above technical solutions / proposals
[21:00] <aschweer> I realise that surveys often don't get much participation, but maybe together with DCAT we could come up with a way to invite more people to give their input? Both embargoes and versioning are probably quite important to a lot of sites that don't have any real "techies" in charge of their DSpace repositories.
[21:01] <mdiggory> Firstly, I'll comment that DCAT in itself is a non-technical group
[21:01] <mdiggory> and the dialog that did occur there was about the features that were wanted and not the implementation itself.
[21:02] <mdiggory> Thus at this point, the dialog with the developer community is about the opposite, getting feedback on the more technical details
[21:02] <tdonohue> aschweer -- I think that's a good question. DCAT has actually been trying to survey on topics already (they recently did an email to various lists), with varying success. They actually may be more appropriate to run such a survey -- though we could suggest it to them, etc. if we felt it important enough
[21:02] <mhwood> I think it's rare that we lack enough implementation ideas. :-/ It's harder to get arms around what should be implemented.
[21:02] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:02] <aschweer> mdiggory: yup, and that's great. I'm wondering if there's a way to involve even more of the community than "just" those represented in DCAT. I don't' know much about how DCAT gets information about what other non-techies want.
[21:03] <mhwood> Sorry, must dash.
[21:03] <mdiggory> By inviting dialog with the non-technical community.
[21:03] <tdonohue> DCAT actually does run their own surveys at times. They were the ones who ran that metadata support survey a while back. So, we can definitely ask if they feel it appropriate to run other surveys, etc.
[21:04] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Quit: Leaving.)
[21:04] <mdiggory> Meeting notes
[21:04] <tdonohue> Also, I should mention that the DCAT list is an open list. It's a google group, and others can join if you are interested (I'd encourage it. Robint & I are on that list)
[21:04] <mdiggory> https://wiki.duraspace.org/display/cmtygp/DCAT+Meeting+Notes+4.10.12
[21:04] <kompewter> [ DCAT Meeting Notes 4.10.12 - Community Groups - DuraSpace Wiki ] - https://wiki.duraspace.org/display/cmtygp/DCAT+Meeting+Notes+4.10.12
[21:04] <tdonohue> DCAT list: http://groups.google.com/group/DSpaceCommunityAdvisoryTeam
[21:05] <mdiggory> And there was additional dialog at SPARC https://atmire.com/website/?q=content/sparc-2012-dspace-user-group
[21:05] <kompewter> [ SPARC 2012: DSpace User Group | atmire ] - https://atmire.com/website/?q=content/sparc-2012-dspace-user-group
[21:05] <mdiggory> http://duraspace.org/sparc-open-access-meeting-and-dspace-user-group-meeting-summaries
[21:05] <kompewter> [ SPARC Open Access Meeting and DSpace User Group Meeting Summaries | DuraSpace ] - http://duraspace.org/sparc-open-access-meeting-and-dspace-user-group-meeting-summaries
[21:06] <mdiggory> I was unaware that there was google group
[21:06] <mdiggory> All I had known of was this
[21:06] <mdiggory> https://wiki.duraspace.org/display/dsforum/DCAT+Discussion+Forum
[21:06] <kompewter> [ DCAT Discussion Forum - DCAT Discussion Forum - DuraSpace Wiki ] - https://wiki.duraspace.org/display/dsforum/DCAT+Discussion+Forum
[21:07] <mdiggory> Its not actually listed on the DCAT page
[21:07] <tdonohue> Hmm... yea, I guess it is not. I thought it was -- must've have been overlooked
[21:07] <tdonohue> I'll mention it to Val
[21:08] <tdonohue> in any case, before we got down this path, we were talking about the Item Versioning stuff. Anything else with that? Or is it also something you are just wanting us to read through, comment on, etc.?
[21:08] <mdiggory> IF thats the case, it should also be considered that it be made public
[21:08] * tdonohue notes we are in "overtime". If you need to head out, feel free.
[21:09] <aschweer> (oh yeah, I need to go to work. bye all)
[21:09] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:09] <sands> cheers all.
[21:09] * sands (~sandsfish@18.189.87.190) Quit (Quit: sands)
[21:09] <tdonohue> mdiggory -- the goal of the DCAT list is much like the goal of the new 'dspace-release' list. Both are "public" but are a bit "unadvertised" as, in order to allow the group to function, you don't want it to get overwhelmed with side-questions.
[21:10] <tdonohue> the DCAT list is meant to be a "working list", much like that new "dspace-release" list
[21:10] <KevinVdV> Needs to run until next week
[21:10] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- The alternative IRC client)
[21:10] <mdiggory> I hope to have the Versioning document refined in the next week. I welcome feedback on implications of the approach of utilizing our DSpace VersioningService and DSpace IdentifierService as implementations separate fromt he dspace api
[21:10] <richardrodgers> need to run also
[21:10] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:11] <mdiggory> likewise, determiniation if integration with DSpace API is a critical expectation from the develoepr community
[21:11] <ryscher> I'm not in favor of hidden lists. If people are having conversations on the wrong list, redirect them. But make the list known so the appropriate people can subscribe.
[21:11] <mdiggory> likewise I agree
[21:12] <tdonohue> ok, well, we can talk to DCAT. They are the ones who created the list to allow them to communicate. Maybe they will then say it should be "private" :)
[21:13] <tdonohue> (i.e. most of the discussions on that list are really about them doing internal organization/administration & setting up their next meetings, etc. Broader discussions get brought elsewhere)
[21:13] <mdiggory> if thats the case, ok
[21:13] <tdonohue> I agree with the sentiment though of not hiding lists. I'm just being realistic that there's really nothing being "hidden". It's a group of people who are discussing how their group functions :)
[21:14] <mdiggory> but I will comment on a slight tangent, that having too many "forums" fragments the community
[21:15] <mdiggory> as such, I do even have concerns about the release list
[21:15] <tdonohue> DCAT list is very much like the 'dspace-release' list. Again, it's a new list for the 3.0 Release Team to discuss how they want to manage/split-up the 3.0 release work. It's a "public" list though, as they don't mind if others listen in, as they do that work.
[21:15] <hpottinger> I'll add that we *do* threaten to put bystanders to work ;-)
[21:15] <mdiggory> but release is a development activity, seems thats what the devel list is for
[21:16] <mdiggory> not clear why its needed
[21:16] <mdiggory> we tried this before and the effect was negative
[21:16] <tdonohue> but, do we really want to crowd the devel list with details like: "who wants to pester mdiggory about getting his promised code into master -- it's late!" :)
[21:16] <mdiggory> isolating dialog on separate lists is fragmenting.
[21:16] <tdonohue> (kidding)
[21:17] <mdiggory> yes we do
[21:17] <tdonohue> I understand. I think we are all open to feedback on that
[21:17] <mdiggory> (not kidding)
[21:17] <tdonohue> so, you really do want to be called out on dspace-devel?
[21:17] <mdiggory> ;-)
[21:17] <mdiggory> thats called open source development
[21:18] <tdonohue> see -- I agree to a point (though I do find this interesting discussion, so I would love to hear others opinions)
[21:18] <mdiggory> devel should be for development related communication, tech should be for users and questions concerning how to use dspace
[21:18] <tdonohue> I see a difference between dspace-devel & dspace-release though (maybe I'm splitting hairs though)
[21:19] <mdiggory> devel should not be about users and questions about how to use dspace, maybe thats drifted and why there seems to be a percieved need?
[21:19] <hpottinger> the R/T discussed this a bit, off-list, and decided another list was desirable, to not adversely affect the signal/noise ratio of the other lists
[21:19] <tdonohue> dspace-devel is more of development discussions / feedback (in a large developer community)
[21:19] <tdonohue> dspace-release is more of a small team "working list" -- geared directly towards them working together to ensure the next release gets out on time
[21:20] <tdonohue> but, again, I'm not against changing that up. But, we'd neeed to talk to the 3.0 Release Team. They are the ones who decided on the 'dspace-release' list option, and they asked me to create the list for them
[21:20] <mdiggory> hmm, see, I think the release process and decisions around it are important development topics that should be addressed with the developer community
[21:21] <tdonohue> mdiggory : I think they would be -- to a point. It's not that release topics wouldn't still be on dspace-devel.
[21:22] <tdonohue> It's just that the 3.0 Release Team needs a place for them to discuss how things are going, etc. (without them just writing private emails to one another)
[21:22] <tdonohue> (or at least that's how I understand it)
[21:23] <mdiggory> I understand the initial concern that may have made this emerge, but having been there previously with dspace-architecture, I'm just raising a flag concerning the idea.
[21:23] <tdonohue> I probably should just let the 3.0 Release Team answer this question though, as I'm not on that team (I'm just helping them with small tasks here and there). So, we might want to start this discussion with them more directly
[21:25] <hpottinger> sorry, had two phone calls
[21:26] <tdonohue> In any case, we're way over time here (again) :) I'm happy to hang around here for a bit to chat more. But, we'll consider the formal meeting "closed" and just consider this "after-meeting discussions"
[21:26] <hpottinger> tdonohue hits the nail on the head here: "It's just that the 3.0 Release Team needs a place for them to discuss how things are going, etc. (without them just writing private emails to one another)"
[21:27] <mdiggory> I'm still not feeling it...
[21:28] <hpottinger> I think any one of us would get pretty nervous if an architecture-related discussion ever came up on the list, as it's not for that kind of discussion, and we'd move it to a different list, but that's the beauty of running a public list, anyone in the community could call us on it if it ever happened.
[21:29] <mdiggory> but htat means we need to subscribe to another list and track that activity to do that calling out
[21:29] <tdonohue> I see pros/cons. I understand the point of trying to be as open as possible (and this may not be as open as if it happened on dspace-devel). But, at least it's more "open" than if it all happened via private emails to one another.
[21:29] <tdonohue> mdiggory -- or you just trust the folks on dspace-release to do that "calling out" for you ;)
[21:31] <mdiggory> sigh.... I'll probably just subscribe to it now that I know it exists. ;-)
[21:32] * hpottinger just dumps all mail into the same inbox, reads it all as best he can, thanks to Outlook on MacOS wonderful lack of support for PST files
[21:33] <mdiggory> ... done
[21:33] <tdonohue> definitely still feel free to start a larger discussion on this. I think we are all open to feedback on this. This is the first time we've ever had a "Release Team", so this is just part of "testing the waters". It can change if people think it needs to change.
[21:34] <mdiggory> I attempt to filter out all mail from hpottinger, but some still creeps in
[21:34] <tdonohue> it's just hard to make a decision here, since hpottinger is currently the only 3.0 Release Team member still in our chat :)
[21:34] <mdiggory> hpottinger: I blame you for all this
[21:35] <tdonohue> haha
[21:35] <mdiggory> :-)
[21:35] <hpottinger> and I gotta run, too, though thanks for the heads up, mdiggory, filter evasion efforts will be redoubled
[21:35] <mdiggory> enjoy... I've got a long overdue meeting with ryscher to get started
[21:36] <hpottinger> I'm willing to take the blame, I'm pretty sure I mentioned the list first, I *hate* private mail list, reply-all stuff
[21:36] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:06] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:31] * ryscher (98033b4c@gateway/web/freenode/ip.152.3.59.76) Quit (Quit: Page closed)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.