Timestamps are in GMT/BST.
[5:57] * cknowles (uid98028@gateway/web/irccloud.com/x-bisvcftdjtdldgzc) has joined #duraspace
[6:29] -sinisalo.freenode.net- *** Looking up your hostname...
[6:29] -sinisalo.freenode.net- *** Checking Ident
[6:29] -sinisalo.freenode.net- *** Found your hostname
[6:29] -sinisalo.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
[10:27] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) has joined #duraspace
[12:29] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:02] * tdonohue (~tdonohue@c-50-178-45-117.hsd1.il.comcast.net) has joined #duraspace
[14:59] * jcreel (~jcreel@jcreel.tamu.edu) has joined #duraspace
[15:00] <tdonohue> Hi all, welcome. It's time for our weekly DSpace Developers Meeting. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-12
[15:00] <kompewter> [ DevMtg 2015-08-12 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-12
[15:01] <tdonohue> First and foremost, we get to tally up the votes with regards to the DSpace Services API work! :)
[15:02] <tdonohue> Checking my email, I don't see any votes since I last counted. So, the totals in the meeting Agenda are the *final tally*! The DSpace Services API will be added to DSpace 6.0 (by a landslide vote)
[15:02] <tdonohue> After this meeting, I'll make sure to close the vote / announce the results on dspace-devel
[15:04] <tdonohue> The next steps here will be to talk more about the process of how we work to get the Services API work into "master". However, as KevinVdV has not yet arrived (he emailed me to say he may be a little late), I'd like to propose coming back to that topic. KevinVdV has obviously done most of the work here thus far, so it'd be best to have him in that discussion
[15:05] <mhwood> Sounds right.
[15:05] <tdonohue> In the meantime, I'd suggest moving on to other topics. We'll loop back to this once KevinVdV shows
[15:06] <tdonohue> I don't have any other significant updates on 6.0 Status (beyond this Services API stuff). But, I did want to mention the sidenote in the Agenda on XOAI
[15:07] <tdonohue> As you may have noticed, the XOAI project (created by Lyncode) has now be migrated to DSpace control. The code is now at: https://github.com/DSpace/xoai/
[15:07] <kompewter> [ DSpace/xoai · GitHub ] - https://github.com/DSpace/xoai/
[15:07] <tdonohue> Joao Melo (of Lyncode) has transitioned this code to us (under the approval of the Committers). DSpace is the only major project using this XOAI codebase, and it was built (by Joao) with DSpace in mind. Recently it has not had as much attention
[15:08] <tdonohue> Joao also has informed me that he plans to submit a PR to DSpace to help us upgrade to his latest version of XOAI (currently we are a major version behind). My hope is that this will be included in 6.0 as well
[15:10] <tdonohue> From this point forward though, we will have full control of XOAI (and Joao Melo is also a DSpace Committer, so he still retains his rights). But, it will let us resolve some annoying OAI bugs that have been open for some time (since they were bugs in XOAI itself)
[15:10] <mhwood> So now all those things we wished would be fixed...we can fix. We're also the new owners of 8 existing issues.
[15:10] <tdonohue> Yes, there are 8 existing "GitHub issues" that came along with XOAI
[15:11] <mhwood> We'll need to identify DSpace issues that are awaiting XOAI changes, and places where we worked around problems.
[15:12] <mhwood> I wonder if any of our existing issues will be addressed by the transition to XOAI 4?
[15:12] <tdonohue> yes, most (if not all) of the DSpace Issues (in our JIRA) relating to XOAI have been labeled "xoai" in JIRA. My understanding is that many of those issues (if not all) may actually be resolved by upgrading Dspace to use XOAI 4 (but that will require verification testing once that upgrade is complete)
[15:13] * KevinVdV (51f1a4a8@gateway/web/freenode/ip.81.241.164.168) has joined #duraspace
[15:13] <mhwood> Good news.
[15:13] <KevinVdV> Hi all finally made it
[15:13] <tdonohue> Hi KevinVdV. we're briefly talking about the XOAI transition. We'll loop back to the Services API stuff shortly (we were waiting for you)
[15:13] <KevinVdV> Ok great
[15:15] <tdonohue> All that said (on XOAI), there definitely is some work to be done to fully "adopt" XOAI into DSpace. We'll need to figure out what to do with those old GitHub issues, we'll need to ensure we get upgraded to XOAI 4 (which Joao says he's doing), and we'll need to adopt a process for managing XOAI releases going forward
[15:15] <mhwood> Will XOAI issue tracking remain in Github (as existing users might expect) or move to Jira? How will we keep informed of new issues, if the former?
[15:17] <tdonohue> mhwood: good question. I'd recommend we transition XOAI to using JIRA to be consistent with DSpace. It's just not something I've gotten to. We also may want to simply treat XOAI issues as DSpace JIRA Tickets (with the "XOAI" label or component).
[15:17] <tdonohue> Currently, my hope/plan is that XOAI is simply treated like the Language Packs (which are released separately but logged in JIRA), for simplicity. If that doesn't work out well, we can always change it later
[15:19] <tdonohue> Any other immediate questions about XOAI or the transition to DSpace control? (If not, I suggest we may want to move back to discussing Services API)
[15:19] <KevinVdV> If XOAi is set in a separate module should we not also fix the following dependency: https://github.com/DSpace/DSpace/blob/master/dspace/pom.xml#162
[15:19] <kompewter> [ DSpace/pom.xml at master · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/blob/master/dspace/pom.xml#162
[15:19] <KevinVdV> Everything in the dspace lib dir depends on this dependency
[15:20] <mhwood> Is there something wrong with it?
[15:21] <KevinVdV> Nothing "wrong" just strange to have such an important depency not part of the core
[15:21] <tdonohue> KevinVdV - I'm not sure that dependency is immediately fixable after moving XOAI over to https://github.com/DSpace/xoai/. To be clear, XOAI is a separate *GitHub Project* still, and there are no immediate plans to merge it into DSpace/DSpace
[15:21] <mhwood> Well, it's only used in the PMH responder and the CLI, no?
[15:21] <KevinVdV> It is
[15:22] <KevinVdV> Reason I bring it up is in order to install the service api that one needs to be replaced by the additions (cannot be commit since it would break OAI indexing)
[15:23] * KevinVdV_ (~KevinVdV@168.164-241-81.adsl-dyn.isp.belgacom.be) has joined #duraspace
[15:23] * KevinVdV (51f1a4a8@gateway/web/freenode/ip.81.241.164.168) Quit (Quit: Page closed)
[15:23] * KevinVdV_ is now known as KevinVdV
[15:23] <tdonohue> KevinVdV: not sure I understand that last statement. I agree with your concern though..it is an "odd" dependency. But, we have no other way (yet) to make OAI PMH CLI tools actually "work" without this dependency
[15:24] <tdonohue> If you have a proposal for a better way though, I think we'd all be open to ideas
[15:24] <mhwood> I don't see why it is odd for DSpace CLI tools doing PMH things to depend on DSpace glue code for XOAI.
[15:25] * tdonohue also notes I do want to get back to discussing next steps for Services API. I'd hate to dwell too much on this one dependency right now
[15:25] <KevinVdV> Ok lets do the dependency later on ;)
[15:25] <mhwood> Yes.
[15:25] <KevinVdV> It will become clear once the steps to install are known
[15:25] <tdonohue> sounds good.
[15:25] <KevinVdV> Which I plan to release with the pull request
[15:26] <tdonohue> So, back to the Services API. As announced previously, Services API is approved for 6.0 (by a landslide vote). So, now, we need to plan out how to get it ready for 6.0
[15:26] <tdonohue> I had detailed some possible steps in the agenda (see 1. b.): https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-12
[15:26] <kompewter> [ DevMtg 2015-08-12 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-12
[15:27] <tdonohue> But, I wanted to be sure we discussed them, tweaked them as necessary, and came up with a final plan
[15:27] <mhwood> I'm not clear on why we need to freeze master if we are going to be making a branch for this.
[15:27] <tdonohue> mhwood: because this change is so massive, if we let other things onto "master" we need to refactor this branch over and over
[15:28] <tdonohue> So, maybe it's a "soft freeze"...but, ideally we don't want "master" changing rapidly while we finish up this feature branch
[15:29] <tdonohue> Plus, we don't want to merge something into master that would essentially be obsolete as soon as the feature branch is merged
[15:29] <mhwood> Merge early, merge often, makes small conflicts instead of big ones.
[15:29] <mhwood> What would be obsoleted?
[15:29] <KevinVdV> Well it isn’t exactly merging, it is rebasing
[15:30] <KevinVdV> & because every class has changed, every rebase is a piece of work
[15:30] <peterdietz> I think there might be some time gaps between checkpoints where the whole refactor is stable, and not introducing issues. i.e. The webapps need many hands to finish the refactor, right?
[15:31] <peterdietz> So. in leiu of destabilizing master for the next month, we'll freeze it. Work on a feature branch until it is mostly stable. That saves us from laborour rebasing, that isn't neccessary
[15:31] <tdonohue> +1 peterdietz
[15:32] <tdonohue> yes, to be clear, the reason we aren't doing this work directly on "master" is that DSpace won't build until this work is complete. Rather than destabilizing all of "master", we'll work off of a unstable feature branch, and merge it over once it is stable
[15:32] <mhwood> I'm not going to argue forever. But this seems like a complicated way of tagging the current master and declaring "no changes except Services until further notice".
[15:33] <KevinVdV> Is there a reason to not put it on master directly ? (Don’t mind…. just wondering)
[15:33] <KevinVdV> Beside to not break the master
[15:33] <pbecker> I don't see any advantages by using a feature branch. Even if we break the master branch: what's the problem? It will get massive changes anyway, by working on the master everyone just see that something big is comming....
[15:34] <tdonohue> it is the same idea. The only reason I was proposing this is that we tend to try and ensure "master" at least compiles/passes unit tests. If we want to make an exception here and just break master, then we could do so, I guess
[15:34] <mhwood> That's essentially my question. If master is frozen, it's the same as just tagging the last known working master.
[15:34] <pbecker> KevinVdV++
[15:34] <pbecker> mhwood: adding a tag seems to be a good idea.
[15:34] <peterdietz> One alternative is to have people make Pull Requests to Kevin's branch... Its just bad practice to have a broken master. Even if we don't support pre-6.x yet
[15:35] <mhwood> The reason you do a feature branch is to expose a massive bit of work for lots of people to work on, while enabling continued work elsewhere. If we forbid the continued work elsewhere, there's no reason to branch.
[15:35] <tdonohue> My only other thought here is that it's *much* easier to monitor for "accidental" PR merges to "master" if we are doing this work elsewhere (feature branch, etc). If everyone is committing to "master" like crazy, we may not notice if some PR button is pressed along the way
[15:36] <KevinVdV> Makes sense Tim
[15:37] <pbecker> We could create PRs as we do normally. At least in the last three years I do not remember any case of a "accidental" merge.
[15:37] <peterdietz> We _could_ make just-in-time security / bug fixes to master. Also. There is a non-zero chance that the whole refactor is a failure, and we'd have to yank it out. If its in master, its a mess. If its an unmerged feature branch, no harm.
[15:37] <tdonohue> +1 peterdietz
[15:37] <peterdietz> Its only a state we'll be in for.. a month?
[15:38] <pbecker> peterdietz: good point.
[15:38] <tdonohue> I honestly think this work is better done in a temporary feature branch.
[15:38] <KevinVdV> I agree now
[15:38] <peterdietz> http://nvie.com/img/git-model@2x.png
[15:38] <pbecker> I agree too.
[15:38] <mhwood> I agree about the feature branch. I'm unconvinced about freezing master.
[15:39] <tdonohue> think about the "freeze" as a "soft freeze". No more merging things just cause it gets a few votes. Instead, please check with those working on Services API *first*
[15:39] <peterdietz> Don't merge Tim's dynamic configs into master, until after the refactor
[15:39] <tdonohue> As peterdietz notes, there may be a need for "just-in-time security/bug fixes" to master even during "freeze"
[15:39] <tdonohue> peterdietz: haha..yea, that too
[15:39] <jcreel> I’m with mhwood. If one worries about the difficulty of merging the branch back into master after master has changed a lot, just regularly pull master into the feature branch while developing.
[15:41] <tdonohue> The problem here is that the Services API is not backwards compatible with the existing Java API. So, not all changes to "master" may end up easy to "rebase/merge" into the active feature branch. It'll almost be a case-by-case decision
[15:41] <pbecker> I would agree to mhwood if this work could have been done in many many small steps. But as it changes almost every class within DSpace I can hardly thing about the work done in a rebase.
[15:42] <pbecker> s/done/necessary
[15:42] <kompewter> pbecker meant to say: I would agree to mhwood if this work could have been necessary in many many small steps. But as it changes almost every class within DSpace I can hardly thing about the work done in a rebase.
[15:42] <tdonohue> That's why I think we need to be *very careful* about stuff going into master (as it could have the side-effect of making the Services API even harder to merge / take longer)
[15:42] * pbecker will work on his regex skills ;)
[15:42] <mhwood> :-)
[15:43] <tdonohue> So, I still think we consider this a "soft-freeze" of "master". If something absolutely has to get in, we can let it in. But, we should make sure it gets approved/noticed by those working on Services API branch
[15:44] <tdonohue> Does that sound reasonable enough?
[15:44] <KevinVdV> Indeed
[15:45] <mhwood> I can work with it.
[15:45] <peterdietz> freezing master. dedicating effort to finalizing the hibernate feature branch, and then eventually merging hibernate branch into master sounds good to me.
[15:46] <pbecker> +1
[15:46] <tdonohue> OK. So, that sounds like our overarching "process" here. Now, we need to dig into a few more details.
[15:46] <mhwood> Are we ready to deal with the flood of PRs unleashed when we merge the branch?
[15:47] <tdonohue> 1) We need a feature branch created. KevinVdV, I'm assuming you'll take this on as soon as you are ready?
[15:47] <KevinVdV> Yes, just wondering how best to approach this
[15:47] <pbecker> How do we communicate the soft-freeze? It would be good to get it out so nobody gets upset about even longer review times than normally...
[15:47] <tdonohue> 2) We need others to claim one or more modules (JSPUI, LNI?, OAI, RDF, REST, SERVICES, SWORD, SWORDv2). So, we may want to create a To-Do list that folks can claim items from
[15:47] <pbecker> (or about need to rebase his/her PRs)
[15:48] <peterdietz> I'll claim REST
[15:48] <tdonohue> pbecker: I aim to send a summary email to dspace-devel. My hope is this "soft-freeze" should only be for a week or two, if we can work together quickly on this
[15:49] <tdonohue> I know Cineca said they'd help on JSPUI
[15:49] <pbecker> I'll claim RDF (even I think Kevin already done most of the work)
[15:49] <peterdietz> If I'm touching REST, and I want to apply a bug fix to REST... Can I make that fix to REST in my patches to services? Or.. keep this stuff disjoint.
[15:49] <mhwood> peterdietz++
[15:50] <KevinVdV> Would you have to make a pull request against the feature branch ?
[15:50] <pbecker> I would prefer if we continue to work with PRs against the feature branch.
[15:50] <peterdietz> Phase 1 = Finish the Refactor. Phase 2 = Services gets merged, and make your PR's against normal DSpace (new normal = hibernate inside)
[15:50] <tdonohue> peterdietz: yes, if you make a PR against the feature branch. We need bug fixes tracked in PRs/JIRA tickets
[15:50] <pbecker> tdonohue++
[15:51] <mhwood> Put me down for OAI.
[15:52] <tdonohue> I agree with pbecker. Perhaps to better follow our own rules, maybe we just create PRs against the feature branch for *all* changes? I.e. we have a PR for "OAI", "REST", etc. (instead of doing direct commits)
[15:52] <mhwood> Sounds better. I don't want other work to go stale.
[15:53] <KevinVdV> Yeah I would prefer Pull Requests as well, so I can take a quick look at it
[15:53] <mhwood> It seems unlikely that we would have to unwind it all and redo master.
[15:53] <pbecker> I think we will have PRs against the feature branch (from people working on getting it mergable) and PRs against our master (for other fixes/features/work). But everyone will know against which branch she/he will create a PR.
[15:55] <tdonohue> Ok, I think we have a plan solidifying here now. Here's what I see as the steps:
[15:56] <tdonohue> (1) KevinVdV will create our initial feature branch and move over the initial code.
[15:56] <tdonohue> (2) We'll take volunteers to create PRs against that new Feature Branch to fix up all other modules (and I'll create a signup list, so we can ensure no one is duplicating effort).
[15:56] <tdonohue> (3) As a PR is finished, notify others and we'll give it a quick review before merging into the active feature branch.
[15:57] <tdonohue> (4) Once all modules are fixed, we'll then do a final quick review/test of feature branch, and then merge it over to "master"
[15:57] <tdonohue> During this process, "master" will be under a "soft freeze". Changes are only allowed if they get reviewed/noticed by the team working on the feature branch
[15:57] <tdonohue> Sound good?
[15:58] <mhwood> Okay.
[15:58] <KevinVdV> Sound good, for information: I should have the pull request ready next week for the DEV meeting. So we can discuss the state of it & how to install
[16:00] <peterdietz> Sounds good to me. Isn't it just git push dspace dspace-service-api, or is it still in flux on your end
[16:00] <KevinVdV> Well I might want to get a few more fixes in
[16:00] <tdonohue> KevinVdV: So, it sounds like you want the initial commit (to the feature branch) to also be a PR? That's fine by me. If so, we can create the feature branch *now* as an exact copy of master, and let you submit the initial PR to that feature branch
[16:00] * lo5an (~lo5an@unaffiliated/lo5an) has joined #duraspace
[16:01] <KevinVdV> That would be great yeah
[16:01] <KevinVdV> Don’t want to start pushing a branch to the dspace git
[16:02] <tdonohue> Ok, sounds good. I'll do the following then later today...(a) Create a JIRA ticket for this (I realized we don't have one yet). (b) Create an initial feature branch immediately for that JIRA ticket work. Then, you can create your PR against that feature branch
[16:03] <tdonohue> I'll also summarize these steps in a followup email to dspace-devel
[16:04] <KevinVdV> & against next week I should have the pull request ready, how to install & docs on how to migrate + complete changelist of the dspace api
[16:04] <tdonohue> Thanks KevinVdV. The sooner we can kick this off the better. So, thanks for working hard to get this all ready quickly
[16:05] <KevinVdV> Yeah I’ll try to get everything in place a bit before the meeting, so you guys can review it before & then we can use next week to clear things up
[16:05] <KevinVdV> If that sounds good ?
[16:05] <pbecker> So the master soft freeze starts as of today?
[16:05] <mhwood> Thank you.
[16:06] <tdonohue> Sounds good, KevinVdV
[16:06] <KevinVdV> I will be present again next week (& should be on time that time, since it is during my evening)
[16:07] <mhwood> I appreciate your taking time out of your evening.
[16:07] <tdonohue> pbecker: yes. I propose that the "soft freeze" begin immediately (to make KevinVdV's PR job easier).
[16:07] <KevinVdV> mhwood: No problem I’ve been working on this pull request for over a year & a half, a lot of time was during my weekends… so an evening won’t matter much ;)
[16:08] <tdonohue> As we are now over our allotted meeting time, I'm not going to cover any of the other topics on the agenda (SourceForge migration updates, UI Working Group mtg notes). There are links / basic details already on there https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-12 If there are questions though, I'm glad to answer them
[16:08] <kompewter> [ DevMtg 2015-08-12 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2015-08-12
[16:08] <pbecker> tdonohue: I totally agree, just wanted to be crystal clear.
[16:09] <tdonohue> As mentioned, I'll summarize these next steps to dspace-devel, and I'll make sure to note the soft freeze, etc. Thanks all for helping to dig through these details :)
[16:09] <KevinVdV> I need to leave now though, need to go eat
[16:09] <KevinVdV> Until next week !
[16:10] * KevinVdV (~KevinVdV@168.164-241-81.adsl-dyn.isp.belgacom.be) Quit (Quit: KevinVdV)
[16:10] <tdonohue> The official meeting is closed (no new topics). But, I will be around if anyone has questions or other topics to bring up informally
[16:10] <jcreel> Perhaps I had an ulterior motive in wanting the master branch not-too-frozen. Texas A&M wanted to get some thoughts on possible PRs.
[16:10] <tdonohue> jcreel: "soft freeze" doesn't mean we won't accept PRs. PRs are *always* welcome. But, we aren't going to merge them until after the Services API stuff gets in
[16:12] <jcreel> A customer here had issues with snippets of fulltext for restricted bitstreams showing in search results, and in the course of addressing this problem we fixed https://jira.duraspace.org/browse/DS-2442 locally
[16:12] <kompewter> [ [DS-2442] Extracted TEXT is always publicly searchable, even if the source file is restricted - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2442
[16:12] <kompewter> [ https://jira.duraspace.org/browse/DS-2442 ] - [DS-2442] Extracted TEXT is always publicly searchable, even if the source file is restricted - DuraSpace JIRA
[16:13] <mhwood> I'm sure we'd all like to see that.
[16:13] <jcreel> So that’s pretty straightforward, we’ll make a PR into DSpace/master
[16:13] <tdonohue> jcreel: yes, sounds like a great bug fix.
[16:14] <jcreel> Then we also need some more things in the build.properties to help with automated deployments. In particular, the Google Analytics key, the useProxies flag, and the request item type. Basic stuff, just a few lines in build.properties and dspace.cfg
[16:15] <tdonohue> I really do hope that this "soft freeze" will only last 1-2 weeks. But, unfortunately, there's no easy way around this...it is a major API refactor, and it is not backwards compatible (which is why the soft freeze is needed)
[16:15] <peterdietz> Sounds fine. Since we're not releasing MASTER any time soon, probably won't merge a PR until after the service clears through.
[16:15] <jcreel> no problem
[16:15] <mhwood> Not backward compatible with build.properties? with CSS?
[16:16] <peterdietz> (personally, I kind of hate build.properties. My deploys use a stock build.properties, and we manage changes through distinct repos/branch just for configs)
[16:16] <tdonohue> jcreel: regarding "build.properties", you might want to look more at DSPR#991. It may end up changing how configs are loaded (and possibly make "build.properties" obsolete)
[16:16] <kompewter> [ https://github.com/DSpace/DSpace/pull/991 ] - DS-2654 : Reloadable Configurations via Apache Commons Configuration by tdonohue
[16:16] <tdonohue> mhwood: my response about API being "not backwards compatible" was a general statement about PRs..not specific to any particular one ;)
[16:17] <mhwood> peterdietz: I have a script that writes e.g. Ds-1234.properties for me. Agreed, it's a pain, especially since building uses *none* of it.
[16:18] <tdonohue> I need to more clearly document the work in #991, but in moving to Apache Commons Configuration, all our "build.properties" custom "magic" is no longer necessary (hence it may become "obsolete" to some extent)
[16:18] <mhwood> Yay!
[16:18] <jcreel> Is that anticipated for the 6 release?
[16:18] <peterdietz> I build once, deploy many. If I had to have a distinct build.properties, and rebuild the code for each variation. My code bases would all still be compiling...
[16:18] <tdonohue> jcreel: yes (at least I'm aiming for 6.0)
[16:19] <tdonohue> jcreel: you can see the "wish list" for 6.0 at: https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status (Anything that is "assigned" is likely to happen. Un-assigned tasks are less likely)
[16:19] <kompewter> [ DSpace Release 6.0 Status - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Release+6.0+Status
[16:20] <tdonohue> (Nothing on the "wish list" is guaranteed yet, until it is voted in, though)
[16:20] <mhwood> peterdietz: that's my objection. None of that gets compiled in, and Maven doesn't make any decisions from it. Ant could apply that stuff to the same artifacts over and over.
[16:21] <tdonohue> With Apache Commons Configuration, all the "variable interpolation" (which build.properties tries to do in a weird custom way) is automatic. It's handled by Commons Configuration itself, and we no longer need to do *any* interpolation (via either Maven or Ant)
[16:22] <mhwood> But at some point it won't even be install-time stuff. As tdonohue says.
[16:22] <tdonohue> (Well, we no longer have to do *any* interpolation in config files... we still may need to do it for things like variables in web.xml files)
[16:23] <mhwood> I would argue that we ought to stop that too, and let the Context supply those data.
[16:23] <tdonohue> +1 (I was just noting the limitation of what Commons Config does for us)
[16:25] <tdonohue> This all reminds me, I need to enhance the basic notes on #991. I'll try to do that today at some point too
[16:25] <jcreel> We’ll hold off on PRs for build.properties stuff (although see https://jira.duraspace.org/browse/DS-1463?jql=text%20~%20%22build.properties%22 )
[16:26] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1463?jql=text%20~%20%22build.properties%22
[16:26] <kompewter> [ https://jira.duraspace.org/browse/DS-1463 ] - [DS-1463] Configuration of Google Analytics in build.properties - DuraSpace JIRA
[16:26] <jcreel> We do one-click build and deploy with Chef, and templating the build.properties was a very nice approach for us.
[16:27] <peterdietz> Interesting. Do you have a write up on this?
[16:28] <tdonohue> jcreel: ok. Just as a note, that 1463 ticket would be "obsolete" if Commons Config was used (PR#991). Commons Config would let you still have a custom "local.cfg" or "build.properties" (if you still want to call it that) which could override ANY default configuration value. Again, I need to write the up
[16:29] <tdonohue> (i.e. once we use Commons Config, you could create a "local.cfg" and put any configs from 'dspace.cfg' or any other '*.cfg' into it. The value in your "local.cfg" would override the default value)
[16:29] <mhwood> Which means that dspace.cfg and modules/*.cfg should disappear into the code.
[16:29] <jcreel> peterdietz, we have some internal wikis and stuff, mostly institution specific, although we have presented at Texas Conference on Digital Libraries.
[16:30] <jcreel> It does sounds like Commons Config is an improvement and compatible with our approach.
[16:31] <tdonohue> jcreel: yes, to be honest, I use build.properties in a similar fashion. I think the Commons Config approach would be backwards compatible with that concept.
[16:32] <pbecker> May I come up with another (short) topic? Does anyone here has plans for a 5.4 release? Does anyone here knows if anyone else has plans?
[16:32] <pbecker> I'm just asking as I created a PR and the corresponding ticket could use a fix version 5.4 but that only makes sense if we plan to release 5.4...
[16:33] <mhwood> Did someone just volunteer to be the 5.4 RC? :-)
[16:34] <peterdietz> I have a minor thing that I could append to 5.x
[16:34] * pbecker looks around like he didn't read mhwood comment. ;-)
[16:35] <mhwood> Hm. If master is frozen, then 5.4 work can't be forward-ported yet. We'd need to keep a list of what to carry forward after Services is merged.
[16:35] <pbecker> the basic question is, whether I should create a version 5.4 in Jira.
[16:36] <tdonohue> I think the quick answer is: currently there are no plans for a 5.4, as there don't seem to be any issues pressing enough to warrant a 5.4 release.
[16:36] <pbecker> mhwood: we won't release 5.4 within the next four weeks. tdonohue mentioned several times that he hopes the master is frozen for not much more than two weeks....
[16:36] <mhwood> I guess that Git would make that list, if we ask it properly.
[16:36] <tdonohue> If an issue warranted a 5.4 release, then we can do one. But all I've seen are minor tickets which likely can wait until 6.0
[16:36] <pbecker> tdonohue: and how do we handle this normally? Do we create it in Jira and see how much fix versions we get together? Or do we wait until we know we'll get enough together?
[16:37] <pbecker> s/how much fix versions/how much tickets with the appropriate fix version
[16:37] <kompewter> pbecker meant to say: tdonohue: and how do we handle this normally? Do we create it in Jira and see how much tickets with the appropriate fix version we get together? Or do we wait until we know we'll get enough together?
[16:38] <tdonohue> Honestly, considering it's August already (and 6.0 is coming in <6 months), at this point, I think we "assume there will NOT be a 5.4" unless something major pops up.
[16:38] <pbecker> and do we track small issues that should be included in case something majors comes along?
[16:40] <tdonohue> pbecker, as long as you tag those bug tickets as being an issue in 5.3, and "fixed in" 6.0, then we can find them in JIRA later on if we need them
[16:40] <mhwood> I see the problem. Probably we should *always* have a "next minor release" open. If we decide not to release it, everything tagged for it gets moved to the next major release.
[16:40] <pbecker> mhwood++
[16:41] <pbecker> tdonohue: I would prefer what mhwood just proposed. Do you have objections?
[16:42] <mhwood> There wouldn't be any mention on the release timeline until a decision is made, to release it or not.
[16:43] <tdonohue> My only concern is that if we have a bunch of bug tickets scheduled for 5.4, are we going to remember to review them for consideration in 6.0 (if 5.4 doesn't happen)?
[16:44] <pbecker> I either have on fix version (the next major release) or two (the next minor AND the next major). But I never use the next minor release only as fix version.
[16:44] <pbecker> I thought that would be a "silent rule"?
[16:45] <mhwood> We'll remember if we put that step on the checklist for beginning a release.
[16:46] <tdonohue> Another concern: If we never do a 5.4 release, what happens when people find tickets that say "Fixed in 5.4"? Are we setting ourselves up for a bunch of later questions about "where's this 5.4 release that is noted in JIRA?"
[16:47] <mhwood> After the decision not to do 5.4, they all become "fixed in 6.0".
[16:47] <tdonohue> I'm open to ideas here. I'm just pointing out that this isn't really an "easy problem".
[16:47] <pbecker> mhwood: In case of DS-2623 I would like to set Fix Version: 5.4, 6.0.
[16:47] <kompewter> [ https://jira.duraspace.org/browse/DS-2623 ] - [DS-2623] Integrity error on file uploads - DuraSpace JIRA
[16:48] <tdonohue> mhwood: but, there's never a point where we truly decide *against* a 5.4. We may say that we aren't doing one this year. But, if we discover a security issue in 2016, we may end up doing a 5.4 security release then
[16:48] <mhwood> Ah.
[16:49] <pbecker> but we do not use the fix version as a final decision. We add fix versions to tickets that still need code reviews. It always just communicates a plan and is not documentational only.
[16:50] <pbecker> I see the fix version field in jira as beeing tentative and the release status pages in confluence as being more concrete.
[16:50] <tdonohue> pbecker: but fix versions on *closed* tickets are the ones I'm concerned on. If a bug fix is closed and states it was "fixed in 5.4", then we are likely to have questions about that 5.4 release at some point
[16:51] <pbecker> true.
[16:52] <pbecker> I don't see that we are going to look over all tickets planed for the next major, when we decide to do another minor release. But do we have other possibilities to mark a ticket as being a possible candidate for another minor release?
[16:52] <pbecker> Perhaps a new label?
[16:52] <mhwood> So what this is all dancing around is: how to communicate a plan to put this code in *the next release*?
[16:52] <tdonohue> there's just not really an "easy answer" here (I wish there was). I tend to not create a JIRA "version" until we are "fairly certain" it will happen. But, that's just been "the way I do it", and I am open to suggestions for changes
[16:53] <pbecker> what about a label: next-minor-candidate?
[16:53] <pbecker> if we decide for a 5.4 we can look up all open tickets with this label.
[16:53] <pbecker> if 6.0 is released and the ticket is closed we do only security fixes in 5.4.
[16:54] <tdonohue> pbecker: why can't you just tag a ticket as: (1) a bug, (2) exists in 5.3, and (3) fixed in 6.0. Then if we do a 5.4, we can simply search for all 5.3 bugs fixed in 6.0 and decide which to add
[16:54] <pbecker> that's fine too, but will we remember to check this?
[16:54] <pbecker> my only doubt is, that we do not check it.
[16:54] <mhwood> Put it on the start-of-release checklist.
[16:55] <tdonohue> +1
[16:55] <pbecker> isn't that to late?
[16:55] <peterdietz> "ok google, remind Pascal to search for 5.4 bugs in 2 months"
[16:56] <pbecker> nevermind.
[16:56] <tdonohue> I don't see how adding a new label increases our likelihood of checking this. But, I do agree, there is a risk of forgetting to do this. We just need a place to add a reminder (just in case)
[16:58] <mhwood> Let's look at this the other way around. What would be a reason to schedule an issue *not for the next release*?
[16:58] <pbecker> it is unclear what is mend by the term "next release".
[16:59] <pbecker> minor or major? and in case of minor: will there be one at all?
[17:01] <tdonohue> as I said, this is "not an easy problem" :) I don't have a great answer here. The best I've been able to figure out is to use JIRA as I described above. Flag tickets as bugs, make sure you note the *most recent version* of DSpace it affects (e.g. 5.3) and the version numbers of the *branches* it was fixed on (e.g. 6.0 for "master" at this point).
[17:01] <peterdietz> I would make a 5.4 jira branch. assign things to it (in addition to 6.0). Have them get merged in 5.x.. If 5.4 is unreleased, then ohh well?
[17:04] <pbecker> peterdietz: that was my initial proposal. But Tim brought up that Jira is also some kind of documentation. Think you find a closed ticket with a Fix Version and start to look for the appropriate version. Would you expect that it may never be released?
[17:04] <pbecker> The only place I found we could put this is https://wiki.duraspace.org/display/DSPACE/ReleaseCoordinating#ReleaseCoordinating-ThingstoDoattheStartofaReleaseCycle
[17:04] <kompewter> [ ReleaseCoordinating - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/ReleaseCoordinating#ReleaseCoordinating-ThingstoDoattheStartofaReleaseCycle
[17:04] <tdonohue> peterdietz: I'll just send you all the questions about "where do I download this 5.4 release? I want this bug fix" ;)
[17:05] <pbecker> But I'm afraid if it will be found there. I wouldn't put it on the page that describes how to make a release, as that is to late to look for possible bugfixes...
[17:06] <peterdietz> I'll point them to: https://github.com/aws/aws-sdk-java/releases
[17:06] <kompewter> [ Releases · aws/aws-sdk-java · GitHub ] - https://github.com/aws/aws-sdk-java/releases
[17:06] <pbecker> s/if it will/it won't
[17:06] <kompewter> pbecker meant to say: But I'm afraid it won't be found there. I wouldn't put it on the page that describes how to make a release, as that is to late to look for possible bugfixes...
[17:06] <peterdietz> AWS SDK Java, cuts a release after each merge. I'll ask whoever asks me for the release to build me a robot. Then, we're good right?
[17:07] <pbecker> sorry I hopped this would be a short and easy question, will have to leave soon.
[17:09] <tdonohue> Unfortunately, the reality here is that it's a very time-dependent answer. If you asked about this in April/May, I'd say "create a 5.4 version, there's likely to be a 5.4 bug fix release". But, since it's August, and *ALL* our effort is going towards 6.0, the answer is different. At this point, I think it's highly UNLIKELY we'll have a 5.4
[17:10] <tdonohue> Or to put it more clearly, 5.4 is really only going to happen if we notice a *massive bug* (unlikely to happen since 5.x has been in the wild for a while now), or a security issue
[17:11] <pbecker> tdonohue: are you asking me to look out for another security issue? ;-)
[17:11] <pbecker> I'll leave it as it is (no note in the wiki, fix version to 6.0) for now.
[17:12] <pbecker> sorry for bugging you on that, but as I expected it was a good idea to ask before I just created a 5.4 version in jira.
[17:12] <tdonohue> So, I wouldn't put a ton of effort into a 5.4 right now, unless you want to lead the release. If *you* really want to see a 5.4 release happen, maybe it can happen (but realize much of everyone's effort is on 6.0 now)
[17:13] <pbecker> I do not have any ambitions regarding a 5.4. I just thought that it would be good to mark candidate PRs that should go in the next minor in case there will be one....
[17:15] <tdonohue> if it's about *PRs* you could simply create a label in GitHub, honestly. Flag it as "5.x" (meaning the PR is compatible with 5.x). You were asking more about JIRA tickets, which are a bit more of a "final record" of changes/fixes in a release.
[17:17] <tdonohue> JIRA tickets drive our "Version History" documentation, hence..I care a bit more about them being "correct". PRs are more for developers, so I don't mind adding more labels/notes there
[17:17] <pbecker> interesting idea. will do, thanks!
[17:19] <mhwood> Good point. PRs represent code, so it makes more sense for them to be scheduled. An issue with no code is just a request.
[17:22] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[17:22] <peterdietz> I'm wondering if https://jira.duraspace.org/browse/DS-2563 will become obsoleted by services?
[17:22] <kompewter> [ [DS-2563] Error releasing database connection - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-2563
[17:22] <kompewter> [ https://jira.duraspace.org/browse/DS-2563 ] - [DS-2563] Error releasing database connection - DuraSpace JIRA
[17:25] <tdonohue> peterdietz: possibly. I suspect we'll need to review database related tickets (in general) and see if they are still applicable for 6.0.
[18:35] * jcreel (~jcreel@jcreel.tamu.edu) Quit (Quit: jcreel)
[18:49] * lo5an (~lo5an@unaffiliated/lo5an) Quit (Ping timeout: 246 seconds)
[18:52] * lo5an (~lo5an@unaffiliated/lo5an) has joined #duraspace
[20:18] * cknowles (uid98028@gateway/web/irccloud.com/x-bisvcftdjtdldgzc) Quit (Quit: Connection closed for inactivity)
[20:32] * kdweeks (~Adium@2001:468:c80:a103:edd6:1051:22d0:b02c) has joined #duraspace
[20:59] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[21:46] * tdonohue (~tdonohue@c-50-178-45-117.hsd1.il.comcast.net) has left #duraspace
[23:02] * lo5an (~lo5an@unaffiliated/lo5an) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
[23:29] * kdweeks (~Adium@2001:468:c80:a103:edd6:1051:22d0:b02c) Quit (Quit: Leaving.)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
