Timestamps are in GMT/BST.
[6:41] -leguin.freenode.net- *** Looking up your hostname...
[6:41] -leguin.freenode.net- *** Checking Ident
[6:41] -leguin.freenode.net- *** Found your hostname
[6:41] -leguin.freenode.net- *** No Ident response
[6:41] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[6:41] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:41] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[9:29] -kloeri- [Global Notice] It's upgrade all the things day which also means lots of reboots. This will unfortunately be quite noisy. Remember connecting to chat.freenode.net, stay calm and don't panic!
[10:49] * cwilper (~cwilper@ec2-54-213-30-97.us-west-2.compute.amazonaws.com) Quit (*.net *.split)
[11:04] -leguin.freenode.net- Server Terminating. Received SIGTERM
[11:04] * Disconnected.
[11:04] -wolfe.freenode.net- *** Looking up your hostname...
[11:04] -wolfe.freenode.net- *** Checking Ident
[11:04] -wolfe.freenode.net- *** Found your hostname
[11:04] -wolfe.freenode.net- *** No Ident response
[12:36] * Disconnected.
[12:36] -sinisalo.freenode.net- *** Looking up your hostname...
[12:36] -sinisalo.freenode.net- *** Checking Ident
[12:36] -sinisalo.freenode.net- *** Found your hostname
[12:36] -sinisalo.freenode.net- *** No Ident response
[12:36] * Disconnected.
[12:36] -sinisalo.freenode.net- *** Looking up your hostname...
[12:36] -sinisalo.freenode.net- *** Checking Ident
[12:36] -sinisalo.freenode.net- *** Found your hostname
[12:36] -sinisalo.freenode.net- *** No Ident response
[12:36] * Disconnected.
[12:36] -sinisalo.freenode.net- *** Looking up your hostname...
[12:36] -sinisalo.freenode.net- *** Checking Ident
[12:36] -sinisalo.freenode.net- *** Found your hostname
[12:36] -sinisalo.freenode.net- *** No Ident response
[12:36] * Disconnected.
[12:36] -sinisalo.freenode.net- *** Looking up your hostname...
[12:36] -sinisalo.freenode.net- *** Checking Ident
[12:36] -sinisalo.freenode.net- *** Found your hostname
[12:36] -sinisalo.freenode.net- *** No Ident response
[12:36] * Disconnected.
[12:36] -cameron.freenode.net- *** Looking up your hostname...
[12:36] -cameron.freenode.net- *** Checking Ident
[12:36] -cameron.freenode.net- *** Found your hostname
[12:36] -cameron.freenode.net- *** No Ident response
[13:23] -cameron.freenode.net- *** Looking up your hostname...
[13:23] -cameron.freenode.net- *** Checking Ident
[13:23] -cameron.freenode.net- *** Found your hostname
[13:23] -cameron.freenode.net- *** No Ident response
[13:23] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[13:23] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[13:23] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[13:26] -kloeri- [Global Notice] And we're done for now with all the rebooting.. except for a single server that will be rebooted when it's done pretending it's a tree. Thank you for using freenode and have a great day.
[13:26] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:31] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[13:31] * cknowles (uid98028@gateway/web/irccloud.com/x-uwwbgsiwiznbjoyu) Quit (Quit: Connection closed for inactivity)
[13:34] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) Quit (Client Quit)
[14:32] * th5 (~th5@unaffiliated/th5) has joined #duraspace
[14:59] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) has joined #duraspace
[15:56] * dyelar (~dyelar@31.158.45.66.cm.sunflower.com) has joined #duraspace
[19:28] * cknowles (uid98028@gateway/web/irccloud.com/x-sdabdoualqfjzwsz) has joined #duraspace
[20:00] <tdonohue> Hi all, welcome, it's time for our weekly DSpace Developers Mtg. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-17
[20:00] <kompewter> [ DevMtg 2016-02-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2016-02-17
[20:01] <tdonohue> While I don't necessarily want to spend a ton of time on it today (unless there are major questions), I wanted to add a reminder of the UI Prototype Challenge feedback/discussions
[20:01] <tdonohue> https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[20:01] <kompewter> [ DSpace UI Prototype Challenge - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+UI+Prototype+Challenge
[20:01] <tdonohue> We are still gathering feedback (from anyone) on our Evaluation Form: https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[20:01] <kompewter> [ DSpace UI Prototype Evaluation Form - Google Sheets ] - https://docs.google.com/spreadsheets/d/1XWxEERh0UXCOo7LhocMMaqbY2u4b6oI11oWOjSp_aSQ/edit
[20:01] * jcreel (~jcreel@nat-165-91-13-46.tamulink.tamu.edu) has joined #duraspace
[20:03] <tdonohue> I will state that, as of this week, we seem to be narrowing down the choices.... Ruby seems to have less support overall, and it's down to a discussion between Java (server-side) or Javascript (client-side primarily). But, we've had feedback from Google Scholar that client-side Javascript may still have SEO implications
[20:03] <tdonohue> The next discussion/meeting is tomorrow (Thurs @ 15:00 UTC). Committers & UI Working Group members have received an invite already
[20:04] <tdonohue> Beyond that, I just wanted to give a brief update on where things stand. If you want your voice to be heard, please join the discussion or add feedback to the form (as we are watching it).
[20:05] <tdonohue> It's likely we will continue with further meetings next week (we've been using Tues/Thurs @ 15UTC as the standard meeting time). But, announcements will be forthcoming
[20:05] <tdonohue> any questions, concerns or comments on all this?
[20:06] <th5> I had tried to look at the submissions last week. It seemed that several of the demos didn't work. Are there particular submissions you suggest focussing on?
[20:06] <hpottinger> tdonohue: re: Anurag's comments on JS... Can we ask for clarification if that applies to Google's own framework, i.e. Angular?
[20:06] <th5> (Is input needed more for evaluating them from a technical standpoint?)
[20:07] <hpottinger> th5: you probably want to watch the video presentations
[20:07] <th5> Ah, thank you
[20:08] <tdonohue> th5: currently, the submissions that show off the narrowed down selections are #1 (Spring Boot + Thymeleaf), #4 (REST + Ember.js), #6 (Spring MVC + other Spring tech), #7 (Spring Boot + Angular.js)
[20:08] <tdonohue> So, if you were to watch 4 demos/videos, I'd suggest watching those 4
[20:08] <hpottinger> Also note that's *not* a 9 hour committment, you can easily skip sections of the videos, one of the prototypes was removed, and one presentation covers several prototypes
[20:10] <th5> Ha, good to know
[20:10] <tdonohue> As a minor clarification here... we are not selecting a "winner" from these prototypes. It may very well be that we select features/technologies from several prototypes (and mix & match a bit). But, those 4 (#1, #4, #6 and #7) show off various technologies still under discussion
[20:10] <th5> That's helpful. Thank you.
[20:11] <tdonohue> hpottinger: regarding Anurag's (from Google Scholar) comments on client-side JS, they *do* apply also to Angular. I specifically mentioned the platforms under consideration in my initial email to him
[20:11] <hpottinger> interesting...
[20:11] <tdonohue> hpottinger: since you should have a forwarded copy of that email thread, you should be able to see my original questions to him
[20:12] <hpottinger> scrolling... scrolling...
[20:12] <tdonohue> Any other pressing questions, comments, concerns here?
[20:13] <hpottinger> an observation: I use robots.txt to shoo robots away from facets and searching in general, and point emphatically at our sitemaps... I'm wondering if the JS concern really applies?
[20:14] <hpottinger> I bet I know Anurag's answer, though...
[20:15] <tdonohue> not sure I follow your question, hpottinger. Anurag seems very insistent that client-side JS is extremely hard to index, and that Google Scholar's indexers specifically *don't* deal with it. Google's spiders supposedly *do* deal with it somewhat (but in a limited fashion)
[20:15] <tdonohue> Not only "extremely hard" but "untrustworthy" or potentially harmful to the indexer itself...if it just goes off and runs any JS code it receives
[20:16] <hpottinger> I bet the heuristics for determining scholarly content rely on being able to at least poke around with the browse/search index a bit
[20:17] <helix84> I do agree with Anurag's concerns, just something occurred to me right now. At OR Anurag said that all they really need is a link to the PDF. They get the metadata from its title page anyway. So worst case, we make that available, we're still borderline usable for Scholar.
[20:17] <tdonohue> If, after tomorrow's meeting, we have more questions for Anurag...he has offered to talk directly to us via a phone discussion next week. So, there are opportunities to follow up with him
[20:17] <hpottinger> perfect
[20:17] <tdonohue> helix84: not sure we want to advertise DSpace as being only "borderline usable/indexable" by Google Scholar ;)
[20:17] <mhwood> Does Scholar pay attention to sitemaps? Do we have to notify them? Do we have to notify them if Google Vanilla already knows about our sitemap?
[20:19] <tdonohue> From my understanding, Google Scholar is separate from Google (in both how their spiders function, and what sites they crawl). That being said, they do "auto-discover" things well, I've found (so I don't know that you have to advertise heavily to them)
[20:19] <tdonohue> I *think* they pay attention to sitemaps, but I'm not sure how that helps a client-side JS app
[20:20] <mhwood> If they use our sitemap, we don't care what they may or may not discover by spidering. Likely they won't spider us if they use a sitemap.
[20:20] <hpottinger> I think we probably just have to keep the JS out of the semantics of the document is the thing: decoration only
[20:21] <tdonohue> mhwood: they have to crawl individual pages for the metadata & PDF links though...those aren't in the sitemap
[20:21] <tdonohue> If those individual pages are just a bunch of javascript (which is the case in single page, JS apps), then there's *nothing* there to crawl without running the JS
[20:22] <mhwood> I see. I've actually written pages that are 100% JS-generated content.
[20:22] <hpottinger> as long as we hand out HTML that contains all of the text the crawler needs to understand the document, the crawler is safe in ignoring the JS
[20:22] <mhwood> Well, this detail probably belongs to the UI meetings.
[20:22] <tdonohue> hpottinger: correct. But, to generate that HTML of "text the crawler needs", you'd need some sort of server-side rendering
[20:23] <hpottinger> so... JS framework isn't totally off the table, but should only apply a "nice coat of paint"
[20:23] <tdonohue> Yes, we're getting deep into the weeds here :) If there are questions that you'd like me to followup with Anurag about, either send them along, or join the UI meeting tomorrow to voice them
[20:24] <tdonohue> hpottinger: correct, and that was stated in Anurag's email. He wants HTML for his spiders...but Javascript is OK for user experience. It's just that all the important parts (metadata, file links) need to be in the HTML part
[20:24] <hpottinger> I can live with that, it's also good for accessibility in general
[20:24] <pbecker> hpottinger++
[20:25] <mhwood> hpottinger++
[20:25] <tdonohue> yep, agreed... hpottinger++
[20:25] <tdonohue> Ok, we should move along now to 6.0 topics :) If you want to talk more about UI stuff & Google Scholar, join us tomorrow at 10am EST / 15:00 UTC
[20:26] <tdonohue> So, with 6.0...I'm going to admit, I've been less "useful" the past few weeks. I've been swamped and have had little time to test/review PRs (but I'm glad others have continued to be more active)
[20:27] <pbecker> Is it still an option to use a JS-framework and to generate static for crawlers server-side? I'm not a friend of that option, as explained in the feedback form, just asking about other opinions.
[20:28] <tdonohue> pbecker: yes...the limitation here is that we *must* have something server-side to generate the primary HTML. Whether that's Java or Javascript or whatever, doesn't much matter. But, it means we'd have to make a more "complex" javascript app (if we wanted to go that route)
[20:28] <pbecker> thanks tdonohue.
[20:28] <tdonohue> 6.0 PRs...we're down to one feature left: DSPR#1162 (which still has issues)
[20:29] <kompewter> [ https://github.com/DSpace/DSpace/pull/1162 ] - DS-2877 Import of ScienceDirect metadata including embargo and linking to or embedding of the final version by LetitiaMukherjee
[20:30] <tdonohue> While it seems like a potentially useful feature...it definitely has some outstanding problems, and it's a matter of how long we wait for fixes
[20:30] <helix84> I'm going to re-test after todays improvement. In my opinion, we should accept it, it just needs some more work to polish it.
[20:31] <pbecker> tdonohue: I expect that we'll find more PRs that still needs some time, when we look into the improvements. So perhaps we could give 1162 some time while we're looking at those?
[20:31] <helix84> pbecker: that would be my suggestion, too
[20:31] <pbecker> :-)
[20:32] <tdonohue> Overall, I agree..we can wait a bit. Though I'd argue we cannot "ship" the bulk ingest part of 1162 without being able to capture the *date* of a publication (as I worry we'd end up with lots of publications in DSpace sites with invalid/incorrect dates)
[20:32] <tdonohue> So, I'm against merging this now...but we can wait a bit longer
[20:32] <pbecker> I agree.
[20:32] <helix84> yeah, issue date and title are critical. DSpace doesn't work right without them.
[20:33] <tdonohue> So, moving along..we've got many improvement PRs still open: https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[20:33] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+is%3Apr+milestone%3A6.0+label%3Aimprovement
[20:34] <tdonohue> Not sure if there's any here we want to touch on now, or if our bigger "point of issue" is the blockers/major bugs...and code changes?
[20:35] <tdonohue> "code tasks" (i mean)
[20:36] <tdonohue> I'm getting the feeling that some of the problems right now (with moving slowly with testing) may be issues with the fact that we have outstanding bug fixes hanging around? Is that fair to give some attention to our bug fixes today, or are their improvements folks want to see reviewed?
[20:37] <mhwood> Bug fixes works for me.
[20:38] <tdonohue> here's our 6.0 bug fixes... https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+label%3Abug+milestone%3A6.0
[20:38] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?q=is%3Aopen+label%3Abug+milestone%3A6.0
[20:38] <tdonohue> There's a ton of them, but my suspicion is we also have a *ton* of low hanging fruit fixes here
[20:39] <hpottinger> DSPR#1291 is one vote away from merger
[20:39] <kompewter> [ https://github.com/DSpace/DSpace/pull/1291 ] - [DS-3056] added and configured xml-maven-plugin to validate all XML by hardyoyo
[20:39] <tdonohue> from the top...(skipping 1292 as WIP)... DSPR#1291
[20:39] <kompewter> [ https://github.com/DSpace/DSpace/pull/1291 ] - [DS-3056] added and configured xml-maven-plugin to validate all XML by hardyoyo
[20:40] <tdonohue> 1291 looks fine to me..but it seems odd to me that it's in the *dspace-api* project POM. Shouldn't it be in the parent POM & inherited (similar to how the "license-header" checks work?). Otherwise, dspace-api is gonna sometimes complain about problems *elsewhere*
[20:41] <tdonohue> i.e. it may "work" but it looks a tad odd
[20:41] <hpottinger> I put it right next to unit tests?
[20:41] <tdonohue> does it only get run during unit tests? Or is it run whenever you build?
[20:41] <hpottinger> only during testing
[20:41] <helix84> dspace-api is one of the forst artifacts, so it may be a positive side-effect to fail early on broken xml
[20:41] <mhwood> It's bound to the "validate" phase.
[20:42] <tdonohue> ok, if it's run only during tests, it's probably OK. I thought this was validating XML on every build (maybe I misunderstood)
[20:42] <mhwood> So any set of phases that runs through validate will run it.
[20:43] <hpottinger> that plugin actually auto-binds to testing, it creates a validate phase under there
[20:43] <mhwood> 'mvn clean install' ought to invoke it, for example.
[20:43] <mhwood> And should IMHO.
[20:43] <hpottinger> tdonohue: I originally wrote that it worked during builds, but revised when I realized that it only works during tests
[20:43] <tdonohue> If it's validating every build, then it should be at the Parent POM...so that individually building "dspace-xmlui" will throw validation errors for XML under that. If it's ONLY validating during unit testing, then it might be OK to do it only in dspace-api
[20:44] <hpottinger> I tried to invoke it during other phases... but the plugin only seemed to work during testing
[20:44] <tdonohue> My point is..currently, if you don't *build* dspace-api, your XML isn't validated. While this "works"...it's not ideal if you want to just build "dspace-xmlui" module (which has a ton of XML...but will never throw a validation error on any of it, unless you also build dspace-api)
[20:45] <tdonohue> If we are *OK* with that as a process, then 1291 is fine. I'm just pointing out the "flaw" here
[20:45] <mhwood> I think I agree that it belongs to the parent.
[20:46] <hpottinger> I did spend time trying to make that happen, and gave up and went with this alternative... I'm happy to try again...
[20:46] <tdonohue> At least to me...validating XML seems most similar to checking license headers...which is done at the Parent level, and inherited to all modules. It's not really clear why we'd *only* validate XML when unit testing happens...but maybe I'm missing something
[20:46] <tdonohue> Either way, honestly 1291 is a good idea. I'm just trying to clarify my point here
[20:47] <mhwood> Yes, it's a good idea, I want it....
[20:47] <tdonohue> +1
[20:47] <helix84> me too, and it works, I tested it on several files
[20:47] <hpottinger> I'm not sure I'll be able to fit in the time to revise it
[20:47] <mhwood> Accept it now and fix the quirks later?
[20:47] <helix84> mhwood++
[20:47] <tdonohue> that's fine, I guess..as long as we log a ticket
[20:48] <tdonohue> "XML validation currently only occurs when dspace-api is built"
[20:48] <pbecker> sorry, have to go.
[20:48] * pbecker (~pbecker@ubwstmapc098.ub.tu-berlin.de) Quit (Quit: Leaving)
[20:48] <tdonohue> moving along now.. DSPR#1277
[20:48] <kompewter> [ https://github.com/DSpace/DSpace/pull/1277 ] - DS-3039 : Fix Community item counting logic. Also cleanup item counting elsewhere in code by tdonohue
[20:49] <tdonohue> This was my fix to Item counting logic. Initially I thought this would fix our unit tests...it did not. But, I still think our Item Counting logic is broken, and this has tests to prove it
[20:50] <tdonohue> It's sitting still at +1
[20:50] <mhwood> So is it ready, then?
[20:50] <helix84> as a side-note, I noticed that upgrading h2 makes performance of integration tests much worse
[20:50] <tdonohue> Anyone have time to try it out or review it sometime soonish?
[20:51] <tdonohue> mhwood: yes. it's ready to go. It works.
[20:51] <helix84> I already did. Since it's a bug fix, I guess we could just merge it.
[20:52] <mhwood> Ah, so "I still think our Item Counting logic is broken" in master, not after this is applied.
[20:52] <tdonohue> Yea to be clear, it includes a new Unit test (which tries to count items with a mapped item) that currently *fails* if run against master. This PR fixes the code to *pass* that new unit test
[20:52] <mhwood> Got it.
[20:53] <tdonohue> So, if anyone has feedback, let me know. Otherwise, I'll likely just merge this later this week...as it's at least better than what is on "master"
[20:53] <mhwood> Please do.
[20:54] <tdonohue> next up, DSPR#1268
[20:54] <kompewter> [ https://github.com/DSpace/DSpace/pull/1268 ] - DS-2987 Solved metadata loss by qualdrop fields in DescribeStep by Gordotron
[20:54] <tdonohue> This seems like a bug, and the bug fix looks reasonable. Needs a test though
[20:56] <tdonohue> going to move along here though..just to review a few more quickly... DSPR#1267
[20:56] <kompewter> [ https://github.com/DSpace/DSpace/pull/1267 ] - DS-3027 ItemImport fix to use the collections file by peterdietz
[20:56] <tdonohue> 1267 looks like a "just merge"..it's one line
[20:57] <mhwood> I agree. Obviously correct.
[20:57] <tdonohue> merged
[20:58] <tdonohue> skipping 1266, as we talked to terry-b about that in #dspace already. It's almost ready
[20:58] <tdonohue> next DSPR#1265
[20:58] <kompewter> [ https://github.com/DSpace/DSpace/pull/1265 ] - [DS-3024] "Administrator" and "Anonymous" groups can be renamed, which would cause them to no longer function in 6.x by mwoodiupui
[20:59] <mhwood> I added tests as requested.
[20:59] <terry-b> Stepping away for some prod work on my end. I may be slow to respond.
[20:59] <mhwood> Lots of discussion but no votes. What else does it need?
[21:01] <tdonohue> excellent...I'm scanning code really quickly
[21:01] <hpottinger> same, so far, looks good
[21:01] <hpottinger> wish I had it for 5x now :-)
[21:01] <hpottinger> (the permanent group idea)
[21:03] <tdonohue> This is looking correct to me.
[21:04] <hpottinger> it adds tests and they all show as passed... looks right...
[21:04] <mhwood> Assuming that they are good tests. :-/
[21:05] <hpottinger> that's what the "looks right" refers to :-)
[21:05] <mhwood> :-)
[21:05] <tdonohue> Only one (perhaps silly) question... what happens if someone goes in and flips this flag (either using the API or SQL) on the "Administrator" or "Anonymous" group? Technically, it seems *possible*...but does that matter?
[21:05] <mhwood> There is no UI to do that at present.
[21:06] <tdonohue> I realize it's not at the UI layer...but it *is* possible at the API or SQL layers
[21:06] <mhwood> Yeah, the proxy object (Group) will cheerfully let you flip the bit either way without any questions.
[21:06] <tdonohue> I'm not sure I have an objection... I'm just letting us all know that it's still *possible* for someone to flip that flag and delete/rename these groups...it's just not *easy*
[21:07] <mhwood> If you reset the bit, then you can rename or delete these groups once again.
[21:07] <mhwood> "Doctor, it hurts when I do this." "Don't do that."
[21:07] <tdonohue> I think the only way to get around that would be to hardcode something into the API though.. literally don't allow that flag to be flipped for Administrator/Anonymous group
[21:08] <hpottinger> or... any group. Permanent means permanent
[21:08] <mhwood> Someone determined to break his repository can do it. There's no way around that.
[21:09] <helix84> mhwood++
[21:09] <mhwood> I could make the Permanent bit permanent. You can turn it on, but you can't turn it off. (If it's off, you can turn it off again.)
[21:09] <mhwood> Is it worth the effort?
[21:09] <helix84> I don't think so
[21:10] <hpottinger> "don't press the don't button!"
[21:10] <tdonohue> But, is it worth adding an "if (Anonymous or Administrator && !permanent) then throw an error" to this method: https://github.com/mwoodiupui/DSpace/blob/DS-3024/dspace-api/src/main/java/org/dspace/eperson/Group.java#L252
[21:10] <kompewter> [ DSpace/Group.java at DS-3024 · mwoodiupui/DSpace · GitHub ] - https://github.com/mwoodiupui/DSpace/blob/DS-3024/dspace-api/src/main/java/org/dspace/eperson/Group.java#L252
[21:10] <kompewter> [ https://jira.duraspace.org/browse/DS-3024 ] - [DS-3024] "Administrator" and "Anonymous" groups can be renamed, which would cause them to no longer function in 6.x - DuraSpace JIRA
[21:11] <tdonohue> I guess what I'm getting at is...I like the direction this took.. Technically you could flag other groups as "permanent" for your repo. But, should we go one last step and say.. "Sorry", we don't let you make Administrator / Anonymous as "non-permanent" at the API level?
[21:11] <mhwood> The whole point of having the bit is that I don't think the ORM layer should know those names.
[21:11] <tdonohue> mhwood: it already does know those names...Group class has them at the top: https://github.com/mwoodiupui/DSpace/blob/DS-3024/dspace-api/src/main/java/org/dspace/eperson/Group.java#L36
[21:11] <kompewter> [ DSpace/Group.java at DS-3024 · mwoodiupui/DSpace · GitHub ] - https://github.com/mwoodiupui/DSpace/blob/DS-3024/dspace-api/src/main/java/org/dspace/eperson/Group.java#L36
[21:11] <kompewter> [ https://jira.duraspace.org/browse/DS-3024 ] - [DS-3024] "Administrator" and "Anonymous" groups can be renamed, which would cause them to no longer function in 6.x - DuraSpace JIRA
[21:12] <mhwood> But it has no logic to deal with them. That's business logic.
[21:12] <tdonohue> Oh, I see what you mean
[21:12] <mhwood> I said it unclearly.
[21:13] <tdonohue> Either way, this is a good step forward. +1 to the PR. I'm just wondering out-loud if there's another step we should take at the API level, to try and dissuade future programmers from calling "setPermanent(false)" on Administrator / Anonymous.
[21:14] <tdonohue> I'll add a +1 though to the PR. I don't think we need to hold it up. Just wondering if there's one more tiny step to take at some point
[21:15] <mhwood> Thank you.
[21:15] <helix84> I wanted to ask a question while we have a quorum here - can I get a preliminary approval to upgrade master to PDFBox 2 when it's released? It seems it will be out any day now.
[21:16] <mhwood> Assuming that it still works, that is tempting.
[21:17] <helix84> yeah, I tested most of the functionality and added PDF thumbnails out of the box, plus several media-filter cleanups
[21:17] <tdonohue> As long as PDFBox 2 doesn't have obvious/major bugs, I'm ok with upgrading still
[21:17] <hpottinger> I'd be OK bumping that dependency version to 2
[21:17] <mhwood> What I mean is that it needs a final check with the released code to make sure that they didn't break anything at the last moment.
[21:17] <helix84> the PR is DSPR#1287
[21:18] <kompewter> [ https://github.com/DSpace/DSpace/pull/1287 ] - DS-3052 improvements to PDFBox-based code by helix84
[21:18] <helix84> mhwood: that is my intention
[21:18] <mhwood> Good.
[21:19] <tdonohue> So, as we're almost 20 mins over time, I'm going to close up for today. I would recommend however, that if anyone has time, it'd be good to "scan" our bug fixes / code tasks for "obvious wins". I'm convinced the number is so large because things have gotten "stuck" (while we were working out various merge conflicts)...now we're playing catchup on getting those obvious fixes in
[21:20] <tdonohue> If you find anything / know of anything that meets that description, I'm also glad to give it a quick code review (just ping me)
[21:20] <mhwood> Thanks!
[21:21] <mhwood> Something has collided with 3052.
[21:22] <helix84> mhwood: the removel of XPDF we just merged :)
[21:22] <helix84> mhwood: I just fixed
[21:22] <mhwood> I see. That was quick.
[21:23] <tdonohue> Oh, and someday soon (maybe this week), I'll try to get back to fixing the merge conflict in DSPR#1251, which I think is a "must have" in this release
[21:23] <kompewter> [ https://github.com/DSpace/DSpace/pull/1251 ] - DS-2188 : Remove remaining artifacts/configs of DBMS Browse system by tdonohue
[21:23] <tdonohue> With that though, I'm going to close up the meeting. Please continue your hard work, and let me know where I can help with code reviews as needed
[21:23] <mhwood> That would be most welcome.
[21:23] <hpottinger> DS-3072
[21:23] <kompewter> [ https://jira.duraspace.org/browse/DS-3072 ] - [DS-3072] XML validation currently only occurs when dspace-api is built - DuraSpace JIRA
[21:24] <mhwood> Thanks for capturing that.
[21:24] <tdonohue> yes, thanks hpottinger
[21:30] <mhwood> I updated documentation and marked 3024 as closed/fixed, but let me know if I should do further work on the doco.
[21:36] <mhwood> Argh, I closed the wrong one. DS-2159 is documented. DS-3024 still to do.
[21:36] <kompewter> [ https://jira.duraspace.org/browse/DS-2159 ] - [DS-2159] Deprecate XPDF in DSpace 5, remove in DSpace 6 - DuraSpace JIRA
[21:36] <kompewter> [ https://jira.duraspace.org/browse/DS-3024 ] - [DS-3024] "Administrator" and "Anonymous" groups can be renamed, which would cause them to no longer function in 6.x - DuraSpace JIRA
[21:39] <hpottinger> off to a consult and testing session, bbl
[22:03] * th5 (~th5@unaffiliated/th5) Quit (Quit: Textual IRC Client: www.textualapp.com)
[22:04] <mhwood> OK, I think 3024 is documented. Tell me if you disagree.
[22:05] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[22:13] -cameron.freenode.net- *** Looking up your hostname...
[22:13] -cameron.freenode.net- *** Checking Ident
[22:13] -cameron.freenode.net- *** Found your hostname
[22:13] -cameron.freenode.net- *** No Ident response
[22:13] * DuraLogBot (~PircBot@webster.duraspace.org) has joined #duraspace
[22:13] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[22:13] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[22:39] * tdonohue (~tdonohue@c-98-226-113-104.hsd1.il.comcast.net) has left #duraspace
[23:11] * cknowles (uid98028@gateway/web/irccloud.com/x-sdabdoualqfjzwsz) Quit (Quit: Connection closed for inactivity)
[23:24] * hpottinger (~hpottinge@mu-162038.dhcp.missouri.edu) Quit (Quit: Leaving, later taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.