Timestamps are in GMT/BST.
[5:37] * cknowles (uid98028@gateway/web/irccloud.com/x-veqjdztmmksqzequ) has joined #duraspace
[6:28] -hobana.freenode.net- *** Looking up your hostname...
[6:28] -hobana.freenode.net- *** Checking Ident
[6:28] -hobana.freenode.net- *** Found your hostname
[6:29] -hobana.freenode.net- *** No Ident response
[6:29] * DuraLogBot (~PircBot@ec2-107-22-210-74.compute-1.amazonaws.com) has joined #duraspace
[6:29] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:29] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[11:47] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[12:07] * cknowles (uid98028@gateway/web/irccloud.com/x-veqjdztmmksqzequ) Quit (Quit: Connection closed for inactivity)
[12:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:02] * cknowles (uid98028@gateway/web/irccloud.com/x-slgxqjvpurephsku) has joined #duraspace
[13:05] * tdonohue (~tdonohue@c-98-212-150-72.hsd1.il.comcast.net) has joined #duraspace
[13:57] * hpottinger (~hpottinge@128.206.253.73) has joined #duraspace
[14:26] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[14:34] * hpottinger (~hpottinge@128.206.253.73) Quit (Ping timeout: 252 seconds)
[15:50] * peterdietz (uid52203@gateway/web/irccloud.com/x-rfyuiplfeycxziuq) has joined #duraspace
[15:55] * kdweeks (~Adium@2001:468:c80:a103:2ca1:ff1f:784e:7737) has joined #duraspace
[16:04] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) has joined #duraspace
[16:21] * pbecker (~anonymous@55d43a5a.access.ecotel.net) has joined #duraspace
[16:33] * pbecker (~anonymous@55d43a5a.access.ecotel.net) Quit (Quit: pbecker)
[17:57] * monikam_ (~Monika_Me@monika.Princeton.EDU) has joined #duraspace
[19:49] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Meeting: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-05
[20:01] <kompewter> [ DevMtg 2015-08-05 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-05
[20:02] <tdonohue> As previously noted (via email / last week), we'll kick things off today by talking about the Services API refactoring from @mire / KevinVdV. https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:02] <kompewter> [ DSpace Service based api - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Service+based+api
[20:03] <tdonohue> This is an opportunity for anyone to voice your opinions, provide feedback on the work, ask questions, etc. The hope is that after this meeting, we'll have enough input to call a vote on whether to consider this API refactoring for inclusion in 6.0
[20:03] * aschweer (~andrea@87.72.69.111.dynamic.snap.net.nz) has joined #duraspace
[20:03] <tdonohue> So, anyone have thoughts/feedback you'd like to share on the work? Or pressing questions/concerns you'd like answered/resolved?
[20:03] <hpottinger> silly question: do we vote on inclusion before a PR?
[20:04] <aschweer> hpottinger: my understanding was, @mire would like reassurance that this will be considered before they put more effort into it (and fair enough)
[20:05] <tdonohue> hpottinger: as this is a major API refactor, I was treating this a bit different than a normal PR. In the case of the Services API, it's gonna be hard to "visually review" *any* PR. Plus, the work won't be *completed* in the initial PR...it'll be started and still need more help to finish up
[20:05] <KevinVdV> Indeed, if you want to see the code you can always checkout: https://github.com/KevinVdV/DSpace/tree/dspace-service-api
[20:05] <kompewter> [ KevinVdV/DSpace at dspace-service-api · GitHub ] - https://github.com/KevinVdV/DSpace/tree/dspace-service-api
[20:05] <aschweer> I imagine the phrasing of the vote would still be along the lines of, we agree to include this for 6 assuming conditions X, Y & Z are met
[20:05] <tdonohue> aschweer +1
[20:05] * shepherdk (~kim@213.229.69.111.dynamic.snap.net.nz) has joined #duraspace
[20:05] <hpottinger> agreed, my silly question was to hopefully tease out the terms of our agreement :-)
[20:06] <tdonohue> hpottinger: it is a good clarification question :) Hopefully that clarifies next steps?
[20:06] <aschweer> I only had a chance to watch the webinar recording yesterday, but I really like (a) the work and (b) this approach (with the documentation+presentation up front)
[20:06] <shepherdk> hi all
[20:06] <tdonohue> hi shepherdk / kshepherd
[20:07] <aschweer> oh yeah, and hi everyone :)
[20:07] <shepherdk> if we're talking about service api, i agree with aschweer (and i only got a chance to watch the video yesterday too!)
[20:08] <tdonohue> Thus far, regarding the Services API refactoring, I've only heard positive feedback (during the webinar, during last week's meeting, etc). I agree with everyone else that I like what I've seen, and I'd like to see this make it into 6.0 myself
[20:08] * terry-b (~terry-b@71-212-24-25.tukw.qwest.net) has joined #duraspace
[20:08] <hpottinger> I also like what I've seen, and would love for it to make it into 6
[20:09] <cknowles> Ditto
[20:09] <aschweer> one of my colleagues raised some performance-related concerns; apparently they've had not so great experiences with hibernate. So some load tests would be good I think, but the layered design would make it possible to switch out hibernate if there really is a problem.
[20:09] * srobbins (~srobbins@libstfsdg02.library.illinois.edu) has joined #duraspace
[20:09] <tdonohue> But, that being said, this is a *major* refactor of the API, and it'll take work on our ends (to help clean up other UIs/interfaces that need refactoring). So, I really was wanting to tease out *any* concerns that may be in folks minds.
[20:09] <hpottinger> the timeframe is really short
[20:09] <KevinVdV> aschweer: indeed I just chose hibernate because it was the “most popular” one
[20:10] <tdonohue> aschweer: good to know / be aware of
[20:10] <hpottinger> 3 months to feature freeze
[20:10] <mhwood> You already voiced mine: it's really big, hard to review. I would have liked to see it come in smaller pieces, but what's done is done.
[20:10] <aschweer> KevinVdV: makes sense to me and I agree with that reasoning -- popular technology makes it easier to get external help if needed.
[20:11] <KevinVdV> mhwood: Doing this in smaller pieces was near impossible …. I just started pulling on a single thread & everything came apart
[20:11] <KevinVdV> so I had to put everything back together
[20:11] <aschweer> I'm a little worried about initial support (after a merge), we don't want to put the whole burden on KevinVdV. There is lots of documentation but often you don't know how good docs are until you actually try using them. I guess if we vote this in, those committers voting in favour have to commit (haha) to get at least somewhat up to speed with this?
[20:11] <mhwood> OK, sometimes that happens.
[20:11] <shepherdk> talking about pulling on threads, i'm about 15-20% throught the lucene removal, i'd estimate
[20:12] <tdonohue> yea, I think this would be rather complex to do in smaller pieces. I think the best way to "review this" honestly will be to bang on it, help fix up other UIs/Interfaces (which will break initially)
[20:13] <KevinVdV> To help things along I have an (evernote) document that details all the changes
[20:13] <tdonohue> aschweer: @mire specifically wants/needs help with this. The initial PR will *only* cover dspace-api and dspace-xmlui (from my understanding). Everything else will be "broken" until fixed. So, we'll want to find someone to help on JSPUI, REST, RDF, SWORD, etc etc
[20:13] <aschweer> tdonohue: agreed but that may be a hard sell locally (that it is a good idea to spend time on this now rather than wait until 6.0 is out and start doing upgrade work then)
[20:13] <KevinVdV> How to get a certain service & which methods require which additional arguments
[20:14] <aschweer> KevinVdV: how spread out is knowledge about this work within @mire? Is it mainly you (+Ben), or others too?
[20:14] <mhwood> aschweer: 6.0 won't *be* out until the remaining UIs work.
[20:14] <tdonohue> aschweer: not sure if you got my point that this will break our build of all other UIs (initially). So, we won't be able to release 6.0 until everything works again :)
[20:15] <aschweer> mhwood: I realise that, just trying to figure out how to "sell" to my boss/clients that I should spend time on this...
[20:15] <mhwood> Do we have to fix LNI?
[20:15] <KevinVdV> Well I’m the primary knowledge base there are a few collaeagues that can help
[20:15] <tdonohue> LNI is deprecated. We could just choose to remove it :)
[20:15] <aschweer> tdonohue: I realise that too, but my clients/boss might say, well then we stay on 5 (which I'd like to avoid!)
[20:15] <cknowles> We might still in LNI to work
[20:16] <KevinVdV> I spent nearly a year working on this in my mancave at home :)
[20:16] <cknowles> Still used for linking to CRIS systems by some UK DSpace users
[20:16] <tdonohue> aschweer: understood. I don't think everyone will have to chip in. but the more we can convince, the better off we are :)
[20:16] <aschweer> KevinVdV: thanks for clarifying. It feels a bit unfair to try and get a promise of support post merge (we don't normally do this really), but given the learning curve, maybe that's needed here?
[20:17] <hpottinger> 3 months to go from all UIs broken to all UIs working...
[20:17] <KevinVdV> I can always help anybody who is having problems, once you “get it” it really becomes copy paste monkey work
[20:18] <mhwood> That's what I was thinking: we'll learn the patterns quickly.
[20:18] <tdonohue> cknowles: if we were to "remove" LNI from the main codebase, I think we should move it to a separate project in GitHub. That way it can still be used/maintained by anyone who wants it (and optionally installed on top of DSpace)
[20:18] <aschweer> KevinVdV that's reassuring too. I guess it's not so much the monkey work I'm worried about, it's what happens once people port local customisations to the layered design and need help wiring them in via spring etc
[20:19] <cknowles> tdonohue: yep think you, Robin and I have discussed this before when it was deprecated
[20:19] <KevinVdV> Well if some people here pitch in, in getting the UI’s to work I think the knowledge will spread out
[20:19] <mhwood> That's probably the easiest bit.
[20:19] <hpottinger> aschweer: I have to assume we all have such customizations that we'll all have to re-wire... so we can all pitch in when we see a question we know the answer to?
[20:19] <KevinVdV> One of the reasons for this work is to make it easier for people to upgrade DSpace versions in the future
[20:20] * monikam_ (~Monika_Me@monika.Princeton.EDU) has left #duraspace
[20:20] <KevinVdV> Because now you can get them in smaller classes instead of overwriting classes thousands of lines long
[20:20] <KevinVdV> So there will be some pain in the short run, but in the long run everyone wins :)
[20:20] <aschweer> Ok, looks like this is going back to, everyone who votes in favour for considering this also agrees to become knowledgeable in this at least to some extent?
[20:21] <mhwood> I agree to that.
[20:21] <shepherdk> i don't see that i have any other option ;)
[20:21] <tdonohue> aschweer +1: Yes, it's gonna need to happen anyhow, as this *will become* the new DSpace API if we vote it in
[20:21] <mhwood> I want to learn JPA anyway.
[20:21] <tdonohue> (so, unless you plan on never working with the DSpace API again, you'll need to learn it) ;)
[20:21] <aschweer> And yes KevinVdV, I'm definitely convinced about the need for this type of work, and I'm not saying you will dump this on us and go on a year-long vacation, I'm just trying to figure out what needs to happen in order for us to accept this into DSpace responsibly :)
[20:22] <hpottinger> I'm glad we're talking about the details of the support now
[20:23] <aschweer> (sorry if I'm not being clear, it's pretty early for me -- I would like to see this in DSpace 6)
[20:23] <tdonohue> So, in the vote, I plan to make it clear that we are essentially "voting in" a new API (as I see it). We will all be expected to learn & use it & support it (and help fix things that are broken immediately). There is no backwards compatibility here.
[20:23] <aschweer> tdonohue +1
[20:24] <mhwood> And help others learn it.
[20:24] <shepherdk> sounds good
[20:24] <hpottinger> tdonohue +1; mhwood +1
[20:24] <aschweer> yup, that sounds great
[20:24] <tdonohue> The role for 6.0 though is to *try* to make it "seamless" for folks who don't have to deal with the API (i.e. most users of DSpace). So, we don't want to make Upgrades extremely painful, if we can help it.
[20:25] <tdonohue> mhwood +1
[20:26] <mhwood> If it's done well (and I don't doubt that) then the pain should be confined to a layer boundary that most people don't see.
[20:26] <tdonohue> Which brings up one more questions. KevinVdV...how does this work in terms of upgrades/installation? Is it just as easy to install DSpace with this new API?
[20:26] <tdonohue> Or, is there more work to be done?
[20:26] <mhwood> "Upgrades" catches my attention, since we have four production instances already. :-)
[20:27] <KevinVdV> Well that depends, if you have code customizations these will need to migrated to use the new API since making backwards compatibility methods wasn’t possible. Other then that I think the only “bigger” change is that the database config has been moved to another file (hibernate config file)
[20:27] <tdonohue> By "upgrades", I'm not talking about highly customized DSpaces...I fully realize they may need to make code changes to use the new API. I'm more considering the 90%+ that just make theme-level tweaks
[20:28] <aschweer> agreed re seamless -- most people probably only touch the config/theme files and maybe do some custom db queries in scripts, and it sounds like except for the UUID work, that's all staying the same (?)
[20:28] <mhwood> tdonohue: me too.
[20:28] <terry-b> Will api overrides be possible from the additions module?
[20:29] <KevinVdV> terry-b: yes api overrides are still posssible from the additions module, but NO need to overwrite the entire classes any more
[20:29] <KevinVdV> Just extend what is there & delcare your new class in a spring config file
[20:29] <terry-b> Good to know. thanks
[20:29] <tdonohue> KevinVdV: I'm assuming "fresh install" is also not affected by this API change / hibernate in any way? Is it still the same installation process?
[20:30] <aschweer> I see there's a (still empty) section in the tutorials part on the wiki that looks like it will give an example for that?
[20:30] <KevinVdV> fresh install (although broken at this time) is not affected
[20:30] <tdonohue> KevinVdV: ok, thanks.
[20:30] <KevinVdV> aschweer: indeed more tutorials will follow soon (once we get some agreement if this is accepted)
[20:31] <aschweer> excellent, thanks KevinVdV and it's fair enough that you'd like agreement first
[20:31] <KevinVdV> You don’t want to know how much time already went into this ;)
[20:31] <aschweer> I saw a few dates in the header comments in your presentation ;)
[20:31] <KevinVdV> But back on the upgrades, the JSP files might be a small problem, the business logic in these files wil need to upgraded
[20:32] <mhwood> Might as well move it out of the JSPs where they need fixing, if it's not much more work.
[20:33] <tdonohue> So, regarding "agreement". I will call a vote (likely tomorrow morning, if I don't get to it tonight). Is there anything else we should "line up"? Do we have a list of "tasks" / ToDos that we can start getting volunteers for? (e.g. so folks can claim JSPUI or OAI or REST or whatever)
[20:33] <shepherdk> we've mentioned other UIs/interfaces etc., what about the things like media-filter, curationtasks, etc? are they included in the initial dspace-api work or will they need volunteers too?
[20:34] <KevinVdV> media-filter, curation tasks (api layer) should all work
[20:34] <shepherdk> ok cool
[20:34] <KevinVdV> Again a lot remains untested (hence should)
[20:34] <KevinVdV> We wanted to focus on getting the XMLUI to work to show that it could work
[20:35] <KevinVdV> Because just working with unit tests that work is one thing
[20:35] <tdonohue> KevinVdV: what is the timeline for a PR (for dspace-api + dspace-xmlui)?
[20:35] <KevinVdV> +-August 14th
[20:35] <tdonohue> ok, thanks. So, it's really only a week or so away. Good to know :)
[20:36] <hpottinger> wow, you're close, then
[20:36] <mhwood> Means that the CFV should go out *soon*.
[20:36] <KevinVdV> Again not everything will work ofc, but it will be a good start to get other people to pitch in :)
[20:37] <KevinVdV> Well I just need a new rebase, fix the fresh install, include the xmlui changes (which a teammate of mine made) & fire the pull request
[20:37] <tdonohue> right, makes sense. The hard part here is that this PR will *break* master (no way around that). It's not gonna compile until we fix everything
[20:37] <hpottinger> from my notes from last week, I show we wanted to merge this work sometime between 8/17 and 9/04
[20:37] <mhwood> Were we going to do a branch for this?
[20:38] <hpottinger> we could do a feature branch and leave master alone...
[20:38] <hpottinger> that's a maintenance chore, but might be prudent
[20:38] <KevinVdV> But IF we do a feature branch, please oh please freeze master …. every rebase is so hard …
[20:38] <tdonohue> Yes, we could a separate feature branch, but we *need* to avoid letting it sit around too long. The quicker this all gets into "master" the better
[20:39] <mhwood> But we want to merge as soon as we have something basically non-broken, and do frequent merges after that until there's no strong reason to keep the branch. It should not take long.
[20:39] <tdonohue> yes, we'll have to essentially "freeze" master temporarily here.
[20:39] <hpottinger> KevinVdV is right, for work of this magnitude, this is no ordinary rebase
[20:39] <shepherdk> i'm getting a bad feeling about that lucene search removal work i'd been doing
[20:39] <KevinVdV> Yeah you will need to rework some of those changes I fear ….
[20:39] <shepherdk> i guess this means i get it in *before* aug 14th if i want to avoid throwing it out / resolving a million conflicts ;)
[20:40] <shepherdk> i did sort of see that coming
[20:40] <hpottinger> lol, race time
[20:40] <KevinVdV> Is the lucene that hard wired into the Dspace ?
[20:40] <tdonohue> yea, shepherdk has volunteered for DS-2187. Remove Lucene
[20:40] <KevinVdV> Isn’t it just a matter of deleting the DSIndexer & DSQuery (I think it is called) classes & all their dependencies ?
[20:40] <kompewter> [ https://jira.duraspace.org/browse/DS-2187 ] - [DS-2187] Remove deprecated Lucene search index support - DuraSpace JIRA
[20:41] <mhwood> Yes, I would be interested to see how these conflict.
[20:41] <shepherdk> KevinVdV: pretty much, there are just other things that you notice once you start tugging on threads as well
[20:41] <tdonohue> I doubt you'd hit *too* many conflicts overall, to be honest. There may be some, but it seems like it should be "rebase-able"
[20:41] <shepherdk> hopefully not too bad, we'll see anyway
[20:41] <KevinVdV> If you have questions I assume you have my email
[20:42] <tdonohue> I have a similar issue forthcoming with my "tugging on the thread that is configuration"... see DSPR#991 ;) But, I'm just going to wait for Services API and then refactor my work
[20:42] <kompewter> [ https://github.com/DSpace/DSpace/pull/991 ] - DS-2654 : Reloadable Configurations via Apache Commons Configuration by tdonohue
[20:43] <tdonohue> But, hey, 6.0 might have a ton of "unraveling" that makes this all easier in the future ;)
[20:43] <aschweer> yeah, looks like maybe we should have saved up that 2.0 version after all ;)
[20:43] <mhwood> In spare time I've been pulling code out of DSpaceKernel and friends in big handfuls, but I don't think it will collide badly.
[20:44] <KevinVdV> mwhood: No I haven’t touched the kernel
[20:44] <KevinVdV> Only needed to make sure it allowed circular references of beans
[20:44] <hpottinger> I'm idly curious what this change will do to MDS
[20:45] <shepherdk> KevinVdV: basically, re: lucene removal: removing classes and dependencies, configs, sitemap references etc. is the easy part - finding all the usages, and the things that depend on them, and the things that depend on them, etc... gets more convuluted. so that's where i'm having to touch many other classes, including in XMLUI, and i guess they'll all look a lot different in your branch
[20:45] <shepherdk> but it should hopefully be fine, especially if i merge before you, teehee
[20:46] <KevinVdV> Yeah … somebody will need to rebase …. but I do hope it isn’t me :p
[20:46] <hpottinger> words to live by
[20:46] <tdonohue> So, it seems like we are getting towards "wrapping up" this discussion. Next steps: (1) Tim will call a vote on dspace-commit (or dspace-devel?). (2) Assuming all goes well, we should "freeze" master temporarily, and rapidly work to help get this into "master" (likely via a temporary feature branch).
[20:47] <hpottinger> is there a github function for freezing a branch?
[20:47] <tdonohue> I think I might just hold this vote in public on dspace-devel? Thoughts, Committers? Is there any reason to keep this a private vote?
[20:47] <shepherdk> i think public is good
[20:48] <hpottinger> +1 public, do we let the community vote?
[20:48] <KevinVdV> Well you want to make sure that IF a non committer votes, he/she understands the changes/benefit
[20:48] <aschweer> I was going to ask, who can vote?
[20:48] <KevinVdV> Because if people vote no because of fear for change …..
[20:49] <hpottinger> that's good info to have, honestly, if there are vetos, we need to figure out why
[20:49] <shepherdk> i was assuming same voting rules, but not hidden on dspace-commit
[20:49] <mhwood> shepherdk++
[20:49] <aschweer> so the only difference would be that it's public which committer voted what?
[20:49] <KevinVdV> Perhaps also make a reason for +1/0/-1 mandatory ?
[20:49] <tdonohue> I doubt we're gonna have many votes. But, to be clear, only Committers have vetoes. Community members cannot veto anything, but they can feel free to vote yes/no, and we'll take their thoughts into consideration
[20:49] <shepherdk> ah ok
[20:50] <tdonohue> have many *community* votes
[20:50] <shepherdk> aschweer: that's a good point i guess
[20:50] <aschweer> tdonohue: ok that sounds good to me, just make it clear in the e-mail :)
[20:50] <KevinVdV> What will be the voting rules ?
[20:51] <tdonohue> Sure, I can make it clear in the email, aschweer
[20:51] <tdonohue> Normal voting rules apply: https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures (except only Committers hold vetoes... so -1 from a community member is just a negative opinion vote)
[20:51] <kompewter> [ Developer Voting Procedures - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[20:51] <shepherdk> KevinVdV++, committers should at least include a comment/reason with their vote
[20:52] <tdonohue> (See *Votes on code modifications* in the Voting Procedures)
[20:52] <tdonohue> maybe I should update this Voting Procedures page first, to make it clear that only Committers hold vetoes
[20:53] <KevinVdV> Indeed, because I honestly don’t want to see this worked schelfed if one person doesn’t like it
[20:53] <tdonohue> (as a -1 from a community member will not cause the vote to fail)
[20:54] <KevinVdV> & what if the vote should fail due to a veto of one person ? (hypothecially)
[20:54] <hpottinger> if there is a committer veto, negotiations begin
[20:54] <mhwood> Find out what is objectionable and try to fix it?
[20:54] <shepherdk> technically, that could still happen.. if the one person is a committer. i seriously doubt it will though.
[20:55] <mhwood> Look at this from the other end: there is no other way for the code to go in.
[20:55] <tdonohue> We'll cross that when it comes to it. But, yes, it tends to go into negotiations. I doubt we'll see a veto too, but we'll see
[20:55] <KevinVdV> mhwood: ofc, ofc, just wondering
[20:56] <KevinVdV> Want to know what we are in for if it does happen
[20:56] <hpottinger> I'm curious about this note about voting on new releases
[20:56] <mhwood> I think that if there is a veto, there will be a lot of pressure to resolve it.
[20:57] * tdonohue is realizing that since we state we follow Apache voting rules, only Committers actually hold "binding votes"
[20:57] <tdonohue> According to Apache Rules: "Who is permitted to vote is, to some extent, a community-specific thing. However, the basic rule is that only PMC members have binding votes, and all others are either discouraged from voting (to keep the noise down) or else have their votes considered of an indicative or advisory nature only."
[20:57] <mhwood> It doesn't mean the end of the proposal; it means there is a serious objection to be addressed. Lots of people want this. They will work to make it happen.
[20:58] <tdonohue> "PMC" is our Committers Group essentially for us
[20:58] <tdonohue> So, I'll clarify all this in the vote. But, we'll do a public vote. Anyone can vote, but only Committer votes are "binding". Non-Committer votes are just considered "advisory" in nature
[20:58] <aschweer> mhwood +1
[20:58] <shepherdk> advisory/preferential votes are still useful though.. and still keep things public, let the community at large engage a bit instead of just "finding out one day"
[20:59] <KevinVdV> Ok agreed, everything is clear for me now
[20:59] <tdonohue> shepherdk +1 I agree. I'll just clarify my language a bit in the vote. I still don't want to *discourage* Community members from voting
[20:59] <shepherdk> tdonohue: yeah that wording seems a bit too harsh to me too.. apache is a slightly different community ;)
[20:59] <mhwood> Voting this one in public is in effect advising the vote method with an information-gathering aspect. :-)
[20:59] <aschweer> might be worth seeing whether the e-mail phrasing can be used to improve that wiki page too?
[21:00] <shepherdk> hpottinger: what's the new releases note? link?
[21:00] <aschweer> as hpottinger noted, some bits on it don't really correspond to our current practice anyway
[21:00] <aschweer> (it is a good starting point, just maybe it's time to revisit the wording)
[21:00] <shepherdk> oh i see it
[21:00] <hpottinger> https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[21:00] <kompewter> [ Developer Voting Procedures - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Developer+Voting+Procedures
[21:01] <hpottinger> 2. Votes on a new release - proposals require a majority are in favor (and at least three +1 votes have been cast)
[21:01] <hpottinger> wut?
[21:01] <hpottinger> :-)
[21:01] <tdonohue> tweaks to language of our voting procedures is welcome (throw them my way)
[21:01] <shepherdk> hpottinger: right, that comes from http://www.apache.org/foundation/voting.html#ReleaseVotes
[21:01] <kompewter> [ Apache Voting Process ] - http://www.apache.org/foundation/voting.html#ReleaseVotes
[21:02] <tdonohue> #2 essentially means: "Majority opinion rules, but at least three Committers should be in favor of the release"
[21:02] <tdonohue> (But #2 doesn't allow for "vetoes")
[21:02] <shepherdk> apache rules also say releases can't be vetoed
[21:02] <tdonohue> Vetoes *only* apply to code changes. They do not apply to releases or policy changes (both of which fall under "majority rules")
[21:02] <hpottinger> sorry, my comment is mainly a distraction, I don't recall ever voting on a release
[21:03] <mhwood> Add it to the release procedure.
[21:03] <tdonohue> we never formally vote on a release, true...but we do discuss whether we think we are ready in meetings ;)
[21:04] <tdonohue> Ok, we're already over one hour here...and I did want to mention the SourceForge to Google Groups migration (for mailing lists)
[21:04] <tdonohue> Assuming no objections, I plan to start migrating our mailing lists one-by-one in the coming weeks. Likely starting at dspace-commit and other lower traffic lists
[21:05] <tdonohue> dspace-general and dspace-tech will wait until the end. Both are massive and may require us to "take down" the list temporarily to migrate them fully
[21:05] <tdonohue> (temporarily = one day at most)
[21:06] <tdonohue> Any objections? Final concerns here?
[21:06] <shepherdk> no objections here, i think sourceforge is basically a risk for dspace right now.
[21:06] <aschweer> no objections from me either, I don't think Google Groups is awesome but it's the best option we have
[21:06] <hpottinger> no objections
[21:06] <shepherdk> btw, my sourceforge account is nearly half as old as i am (random fact of the day)
[21:06] <mhwood> I have nothng to add.
[21:06] <tdonohue> I agree with both points, shepherdk and aschweer
[21:06] <shepherdk> yeah i'm not big on google groups, but.. can't think of a better suggestion so will go with majority opinion on that ;)
[21:07] <tdonohue> I'm mostly choosing GG cause its the "known entity" in our space. Everyone else uses it, so if we hit problems, we can turn to Fedora, Hydra, Islandora, etc. etc to see how they dealt with it too
[21:08] <aschweer> yeah. The only real alternative would be Duraspace running its own mailman I guess, and that definitely isn't a good use of Duraspace time.
[21:09] <mhwood> I have to go. Cheers, all.
[21:09] <terry-b> For new users, the searchable archive may be easier to locate in GG
[21:09] <tdonohue> Last quick note for today: As announced on dspace-general, the first UI Working Group meeting will be Monday (Aug 10) at 15UTC. Anyone is welcome to attend. We hope to get this Working Group established/kicked off via that meeting and thus start the UI pilot process
[21:09] <shepherdk> cheers mhwood
[21:09] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:10] <aschweer> are there plans for recording the meeting? 15UTC is pretty much the worst time possible in this part of the world
[21:10] <hpottinger> tdonohue: I'll be on vacation on the 10th, but would love to participate later on
[21:10] <aschweer> (or at least minutes, or something)
[21:10] <shepherdk> so there is a working group now?
[21:10] <shepherdk> or this meeting is to establish a working group?
[21:10] <tdonohue> aschweer: sorry, I know. :( There will definitely be minutes. The time was decided based on a quick survey of anyone who told Jonathan or I they wanted to be part of the UI piloting process (at OR15)
[21:11] <tdonohue> this meeting is to establish the working group. One does not yet exist
[21:11] <tdonohue> We just have a list of folks who expressed interest in helping. The goal of the meeting is to bring those folks together (and any others interested) to formalize it a bit more
[21:11] <aschweer> tdonohue fair enough. This may have to be a case of, I'd love to be a part of this but I'm really not sure I can put time towards it. But it would be great to have a way of knowing what's being discussed.
[21:12] <tdonohue> To clarify though, *anyone* will still be welcome to take part in pilots, or offer advice/thoughts. I'll make sure there's opportunities for that
[21:12] <shepherdk> yeah, i think we always lose out on that front ;) i am still interested, but will just have to see what happens.
[21:13] <tdonohue> The goal of the working group is really to help us formalize the process of how to kick off pilots, etc. The "draft" working group charge is at: https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Working+Group
[21:13] <kompewter> [ DSpace UI Working Group - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Working+Group
[21:14] <hpottinger> this is going to be a busy Fall
[21:14] <tdonohue> So, even if you are not on the working group, you can still be on a pilot project, etc. There's also no requirement to be on a pilot project if you choose to be on the Working Group.
[21:15] <tdonohue> hpottinger: yes. you said it :) I wish there was a better way.
[21:15] <aschweer> tdonohue: thanks for clarifying, that is helpful (I hadn't read the page, I saw 3am and thought ok I can't be a part of that anyway)
[21:16] <tdonohue> Ok, anything else anyone has to bring up for today? We're now 15+ mins over, so I won't bring up any more topics myself
[21:17] <shepherdk> jsut that i'm sorry about DS-2694 if that was my fault
[21:17] <kompewter> [ https://jira.duraspace.org/browse/DS-2694 ] - [DS-2694] DSpace 5.3 Source Code Download Issue - DuraSpace JIRA
[21:17] <hpottinger> shepherdk: nope, not your fault
[21:18] <shepherdk> i did so much testing, but testing validity of image files in distribution zips was not one of the things i thought to test
[21:18] <tdonohue> shepherdk: nope. It was our Maven assembly config's fault
[21:18] <shepherdk> and it seemed to get reported+fixed while i was blissfully unaware and asleep, so i just woke up one morning to read about it ;)
[21:18] <shepherdk> ok that's cool
[21:19] <tdonohue> mhwood had figured it out previously for *.zip files...we just never realized it also affected all image files. But, luckily mhwood had a quick fix
[21:19] <tdonohue> Ok, hearing no other topics, we'll close up today's meeting. I'll still be around for a while, if anything comes up
[21:20] <shepherdk> cheers all, better get to the office before they notice i'm not there ;)
[21:20] <cknowles> tdonohue: happy to be note taker for Monday's meeting if you need a volunteer
[21:21] <KevinVdV> Is going to sleep because in this part of the world it is already 23:21 & I need to work tomorrow
[21:21] <tdonohue> cknowles: wow! a note taker volunteer prior to the meeting, I like it! :) Yes, we'll gladly take you up on that
[21:21] * KevinVdV (~KevinVdV@d54C5104D.access.telenet.be) Quit (Quit: KevinVdV)
[21:21] <aschweer> thanks in advance cknowles :)
[21:21] <cknowles> If I volunteer for the small things I don't have to do the big ones, right?
[21:22] <shepherdk> hehe
[21:22] <tdonohue> perhaps true :)
[21:23] <cknowles> :)
[21:23] <shepherdk> i should note that cknowles has done even more good work on the UI functionality mapping spreadsheet thingy, and i have been not-so-good at keeping up and adding to it (but i will try)
[21:24] <cknowles> Not added anything for a wee while though
[21:24] <hpottinger> two observations: you lot are in the loggeed channel, and the meeting is over ;-)
[21:25] <shepherdk> sorry?
[21:25] <shepherdk> anyway, yes, i need to go to work. cheers all!
[21:26] <hpottinger> I'm not complaining, just, you know, that bot there is nosey.
[21:26] * hpottinger points at DuraLogBot.
[21:27] * aschweer (~andrea@87.72.69.111.dynamic.snap.net.nz) Quit (Quit: leaving)
[21:31] * shepherdk (~kim@213.229.69.111.dynamic.snap.net.nz) Quit (Quit: Leaving)
[21:39] * hpottinger (~hpottinge@mu-160190.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
[21:40] * tdonohue (~tdonohue@c-98-212-150-72.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:24] * kdweeks (~Adium@2001:468:c80:a103:2ca1:ff1f:784e:7737) Quit (Quit: Leaving.)
[23:47] * cknowles (uid98028@gateway/web/irccloud.com/x-slgxqjvpurephsku) Quit (Quit: Connection closed for inactivity)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.