Timestamps are in GMT/BST.
[6:47] -asimov.freenode.net- *** Looking up your hostname...
[6:47] -asimov.freenode.net- *** Checking Ident
[6:47] -asimov.freenode.net- *** Found your hostname
[6:47] -asimov.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:47] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:47] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:11] * misilot (~misilot@p-body.lib.fit.edu) Quit (*.net *.split)
[8:13] * misilot (~misilot@p-body.lib.fit.edu) has joined #duraspace
[12:55] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[14:00] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[14:44] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[17:15] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[18:58] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:13] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[19:52] * bollini (~chatzilla@95.235.208.246) has joined #duraspace
[19:53] * PeterDietz (~peterdiet@128.146.173.70) has joined #duraspace
[20:00] <tdonohue> Hi All, it's time for our weekly DSpace Developers Meeting. Today's agenda is up at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-21
[20:00] <kompewter> [ DevMtg 2013-08-21 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-21
[20:00] <tdonohue> We'll start things off with a few Pull Request reviews. Here's our PR listing: https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:00] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <mhwood> Could we revisit #210? I've cleaned it up.
[20:01] <tdonohue> Sure thing.. we can start at #210 then. https://github.com/DSpace/DSpace/pull/210
[20:01] <kompewter> [ [DS-1269] EmailService to encapsulate the sending of mail by mwoodiupui · Pull Request #210 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/210
[20:02] <hpottinger> merge button is green, and Travis vouches for it...
[20:02] <helix84> mhwood: so is andrea's concern adressed?
[20:03] <bollini> I have tested it, +1 for me
[20:03] <helix84> ok
[20:03] <tdonohue> I'm +1 this. I'm just skimming it, but it all looks fine at a glance. Would be nice to get in early
[20:04] <hpottinger> push the button, Max!
[20:04] <mhwood> Total is +2 with no -1s.
[20:05] <mhwood> It's pulled.
[20:05] <mhwood> Thanks.
[20:05] <hpottinger> Progress!
[20:05] <tdonohue> One minor note...looks like it adds a config ("mail.session.name") which needs docs
[20:05] <PeterDietz> yeah, I was going to say I don't have any reservations
[20:06] <mhwood> I will document it. Thanks for the reminder.
[20:06] <tdonohue> no problem
[20:06] <tdonohue> ok, we'll move on now... the next PR on our list is #222 https://github.com/DSpace/DSpace/pull/222
[20:06] <kompewter> [ Implementation of CAS (Single Sign-On) authentication for DSpace by nkneumann · Pull Request #222 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/222
[20:07] <helix84> I just added a changes-config label to Ds-1269
[20:08] <helix84> I might be able to test this, but I totally can't promise a date
[20:09] * bram-atmire (~bram@94-225-35-170.access.telenet.be) has joined #duraspace
[20:09] <tdonohue> Looks like mhwood had a lot of good comments/suggestions on this PR (which have not yet been fixed)
[20:09] <helix84> if this works for those 2 guys who developed it together and if there are no major concerns, I'd say merge it and iron it out during testathon
[20:09] <helix84> btw misilot is here today
[20:11] <tdonohue> I think this idea/code looks good in general, but there are some issues...namely the ones mhwood pointed out in comments. CAS Auth should NOT be enabled by default, and it needs to avoid adding specific code to other areas of the codebase
[20:11] <helix84> so, it seems this is an auth method at least 5 people are interested in (including me)
[20:12] <mhwood> Maybe I should fork it and submit some changes to the author.
[20:12] <helix84> mhwood: good idea
[20:12] <tdonohue> Once things are cleaned up, I think it'd be a good addition. It just cannot be merged as-is, as it does some "not great" things (like replace default PasswordAuthentication with CASAuthentication in authentication.cfg)
[20:13] <tdonohue> yep, if you are willing, that'd be great. Most of the fixes seem like one-liners...but, a few are important to fix before merging
[20:13] <mhwood> I will do that.
[20:14] <bollini> mark I read that a JSPUI help is need, feel free to send me an email with some context to make a final review/cleanup for JSPUI
[20:14] <helix84> we also need to check license of the cas.casclient dependency
[20:14] <tdonohue> Ok, let's do one more PR for today... #227 : https://github.com/DSpace/DSpace/pull/227
[20:14] <kompewter> [ DS-1561 build.properties breaks no-auth SMTP by helix84 · Pull Request #227 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/227
[20:14] <mhwood> Thank you bollini.
[20:16] <mhwood> 227 sounds like a thing we should fix, but I had some concern about the expression.
[20:16] <bollini> I have just added a comment
[20:16] <bollini> we can use StringUtils.isNotBlank
[20:17] <helix84> I honestly can't remember what I meant. If someone wants to take it, I'd appreciate it.
[20:17] <PeterDietz> I forgot about StringUtils, and isNotBlank. Another project I'm working on is littered with dozens of !=null && !=""
[20:18] <tdonohue> If someone wants to fix up PR #227, it seems like a good candidate to "just merge". It should be a one-line fix.
[20:19] <PeterDietz> PR#227 itself is also one-line
[20:20] <tdonohue> to answer helix84's earlier note about PR #222, it looks like the "casclient" is a BSD-style license: http://search.maven.org/remotecontent?filepath=cas/casclient/2.1.1/casclient-2.1.1.pom (license reported as: http://www.yale.edu/tp/cas/LICENSE). So, it should be OK.
[20:20] <tdonohue> So, regarding PR #227, anyone want to fix that one line and merge it?
[20:21] <bollini> I'm just opening my workspace...
[20:22] <helix84> tdonohue: thanks for checking, I added it as a comment to the issue
[20:22] <tdonohue> ok. well, I'm gonna move on to other meeting topics for now. It'd be nice if someone can just clean up #227
[20:23] <helix84> Ehm, please check if it really needs cleaning up. The original logic might have worked, I don't remember now.
[20:24] <bollini> helix84: ok, I will check
[20:24] <tdonohue> Ok, so the other topic is the ever-present DSpace 4.0 Release. If I'm not mistaken, we have a schedule (which I pasted into the agenda page)
[20:24] <bollini> sorry a last pr https://github.com/DSpace/DSpace/pull/286
[20:24] <kompewter> [ DS-1622 Porting of the Login As feature to JSPUI by abollini · Pull Request #286 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/286
[20:24] <tdonohue> So, I think the next steps are to (1) get this schedule over on the 4.0 Release Notes, and (2) Announce it to the community / make people aware.
[20:25] <mhwood> Yes. I can do that.
[20:25] <bollini> can you check my last comment? I have suggested to change a configuration to use the same value in jspui and xmlui. Is it fine for you? if so I will be able to complete this PR in the next few days
[20:26] <bollini> mhwood: thanks to get you this task!
[20:26] <tdonohue> bollini: Regarding PR#286, yes it makes sense for XMLUI & JSPUI to share the same "webui.user.assumelogin" configuration since it's the same feature across both UIs
[20:27] <helix84> i added the appropriate labels to the related issue
[20:28] <tdonohue> mhwood: Ok, sounds great! If you need another set of eyes in drafting the 4.0 schedule announcement, feel free to let me know. Glad to offer help, if you need it, but the announcement need not be anything "fancy"
[20:28] <mhwood> tdonohue: thank you.
[20:29] <tdonohue> So, as for the rest of the meeting, is there anything else 4.0 related that the Release Team (or others) would like to discuss? Should we review any other specific PRs or similar? I'm open for ideas... I just wanted to make sure to leave time for 4.0 discussions
[20:30] <bram-atmire> I've got a few 4.0 points
[20:30] <bram-atmire> easiest one first:
[20:30] <bram-atmire> I volunteer to wrap up the release page with short descriptions & icons for the new features, like the last 2 releases
[20:30] <mhwood> Now to get together a list of what we think is already targeting 4.0 and get in touch with the authors to coordinate and schedule.
[20:31] <mhwood> bram-atmire: that sounds good. Thank you!
[20:31] <tdonohue> +1 bram-atmire: that'd be great! Folks have always liked that visual touch to the release notes
[20:31] <hpottinger> bram-atmire has a suggestion about following up with RichardJones about a ResourceSync contribution (at the end of the release notes)
[20:32] <bram-atmire> which easily transitions into what these features need to link to … docs
[20:32] <bram-atmire> Does anyone share the feeling/idea to do some more structural improvements to the docs in the light of 4.0 ?
[20:33] <helix84> bram-atmire: apart from the fact that we should completely rewrite our Installation page? ;)
[20:33] * hpottinger believes helix84 just volunteered
[20:33] <tdonohue> RE: ResourceSync. I distinctly recall RichardJones mentioning (at OR13) that ResourceSync for DSpace would not be stable in time for 4.0. We can touch base with him again to be sure, but I recall him saying that.
[20:33] <bram-atmire> tdonohue I remember something similar yes
[20:34] <tdonohue> RE: Docs. I'd love to see them improved upon. Installation is a page that needs it. As does the Upgrade page perhaps
[20:34] <helix84> hpottinger: I've been meaning to do that for over a year. I'm fairly sure I won't manage to do that in time.
[20:34] <mhwood> Only the server side of RS is done, so far as I can tell. There's no client side. (That is: there's not enough to use it for sync.ing two DSpaces.)
[20:34] <bram-atmire> well, there are personally a few extra docs pages I want to tackle before mid october, they are all entered as jira tickets
[20:34] <bram-atmire> DS-1516
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1516 ] - [#DS-1516] Authority Control Documentation - DuraSpace JIRA
[20:34] <bram-atmire> DS-1509
[20:34] <kompewter> [ https://jira.duraspace.org/browse/DS-1509 ] - [#DS-1509] Item Mapper documentation - DuraSpace JIRA
[20:35] <bram-atmire> DS-880
[20:35] <kompewter> [ https://jira.duraspace.org/browse/DS-880 ] - [#DS-880] Better documentation for permissions - DuraSpace JIRA
[20:35] <bram-atmire> and then the uglier and more elaborate task of i18n docs still sitting on the general DSpace wiki instead of the actual docs
[20:35] <hpottinger> I also intend to work on the Shib "lazy session" documentation
[20:36] <bram-atmire> but all things considered, these things are all pretty straight forward, they just need to get done
[20:36] <bram-atmire> but in terms of the organization of the tree of pages i'm still struggling to think about a better way to organize the tree
[20:36] <bram-atmire> so if anyone has any ideas there, I think there's some room for improving stuff
[20:37] <hpottinger> at one time there was a pointer to the "current" docs, which I've hit when googling
[20:37] <bram-atmire> or maybe we could have a separate meeting moment, focused on brainstorming around getting a better tree
[20:37] <helix84> bram-atmire: It was my suggestion about 2 years ago that we need to separate user docs and admin docs (and perhaps even admin docs into howto and reference)
[20:38] <tdonohue> I'd love to see us start to "reorganize" docs into "User's Guide" and "Administrator's Guide". Right now, we have a little of both sprinkled throughout.
[20:38] <bram-atmire> the top level nodes configuration/customization/advanced customization/System administration don't seem super clear anymore
[20:38] <tdonohue> A good example of a better docs organization structure could actually be the sidebar of the Atlassian Confluence Docs: https://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home ("101", "User's Guide", "Admin's Guide", "Install & Upgrade Guide", "Release Notes", etc)
[20:39] <kompewter> [ Confluence Documentation Home - Confluence Latest - Atlassian Documentation ] - https://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home
[20:39] <bram-atmire> user e.g. end user? who is normally served in JSPUI with the dspace help pages?
[20:39] <tdonohue> But, getting to that model could take some work
[20:39] <helix84> Some of you might know about the Sun Scholar wiki which is written in the HOWTO style and is Ubuntu-specific. Once I asked the author, Hilton Gibson, whether he would like to work on the official docs instead, but he refused (his wiki covers a broader scope than just dspace admin docs)
[20:39] <hpottinger> Install and Upgrade, important keywords, especially for a harried devops type just trying to figure out how to get going
[20:40] <tdonohue> "user" in my mind would be "repository manager". "admin" would be "system administrator in charge of installing/configuring DSpace"
[20:41] <helix84> yeah, there's a blurred line, some UI elements are used by both repo manager and admin
[20:41] <bram-atmire> I'm not sure whether the split can really be made without overlaps. Because if there are overlaps we can end up with a situation where we have to manage the same information in two different places
[20:42] <helix84> maybe those shared pieces could be made a separate wiki page and that page shared by both admin and user docs
[20:42] <mhwood> OK, there's the System Administrator who runs the machine and installs things. There's the Repository Manager who sets up the overall repo. There are Community and Collection Managers delegated powers and work by the R.M. There are end users.
[20:43] <mhwood> The trick is knowing which role you are working in. You might be any or all of those people.
[20:43] <helix84> even the end users might just be visitors or they might be submitters - another blurred line
[20:43] <mhwood> So maybe the way is to first explain the roles and then organize by role?
[20:43] <helix84> I'll try to find my original proposal, I think we did agree on splitting up howto vs. reference
[20:44] <tdonohue> we cannot create docs for "casual visitors", as each repo is different... That's like saying that WordPress needs to create docs for "anyone who is browsing a WordPress-based site) ;)
[20:44] <hpottinger> so, this is starting to sound like user-centered design: identify stakeholders, develop user personas
[20:45] <tdonohue> This is part of the reason I was looking for a different 'generic' term... It's more about separating out the "Config/Setup/Install/Upgrade" docs from the "Here's how you actually use DSpace" Docs. So, maybe it's "Administrative" vs. "Usage" docs or something
[20:46] <mhwood> That sounds good.
[20:46] <tdonohue> We could parse the "Usage" into every possible user role..but, I don't think that's absolutely necessary in the short term. It's just important to try and seperate "Usage" from "Administration"
[20:46] <helix84> found the original discussion (at the end), this might have been the first time I spoke up in DevMtg: http://irclogs.duraspace.org/index.php?date=2011-02-16
[20:46] <kompewter> [ IRC Log for #duraspace on irc.freenode.net, collected by DuraLogBot ] - http://irclogs.duraspace.org/index.php?date=2011-02-16
[20:47] <tdonohue> And, yea, there still may be some overlap between "Administration" & "Usage"...but, we can interlink wiki pages as needed, and similar. You can also create the same page in two sections, and just have one page "embed" the contents of the other.
[20:50] <mhwood> I just entered a sketch of documentation for mail.session.name, but it could be improved.
[20:51] <tdonohue> In any case, not sure if I've taken this off track. My point is we should not worry about trying to create docs for every-possible user role. The most important two are Admin tasks & Usage (mostly UI) tasks
[20:51] <bollini> FYI, I'm going to merge https://github.com/DSpace/DSpace/pull/288 it is more than one line but pretty trivial (I found other problem with empty configuration - alert.recipient)
[20:51] <kompewter> [ DS-1561 build.properties breaks no-auth SMTP by abollini · Pull Request #288 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/288
[20:51] <tdonohue> It's just an idea to throw out there...but, I'm not sure how much time I'll have to devote towards this for 4.0 (that's still too be determined)
[20:53] <helix84> I think the low hanging friut is to isolate the reference parts - like description of config options
[20:53] <helix84> these are already duplicated with config file comments
[20:53] <tdonohue> bollini: those changes to #288 look reasonable...but, it looks like it's currently "unmergeable" (no green button).
[20:54] <helix84> if we ever move configuration to the admin UI, we'll also want the descriptions there, so we need to figure out a way forward
[20:54] <bollini> tdonohue: yes, I just see it... it is the merge of the mark pull request... I try to fix
[20:55] <bram-atmire> good discussion!
[20:55] <tdonohue> helix84: yea, config stuff would be nice to clean up in the documentation & isolate better. For now, I think we do need it in the Docs, as it sometimes adds more details/examples than we can provide in the config file comments.
[20:55] <bram-atmire> Can the DSDOC4X space be used to "try" out certain improvements or should we reach a formal consensus before changing stuff?
[20:57] <helix84> bram-atmire: I'd encourage you to be bold and make any improvements. That way you won't get stuck waiting on review which may never come. In case of any disagreements, we can still revert those.
[20:57] <mhwood> Maybe the space could be copied for experimenting? I don't want to make a lot of rework, but I also don't want to have to chase the locations for things we are trying to document, as they move about.
[20:58] <tdonohue> bram-atmire: Sure! If you have time to devote, I think it's fine to play around. The only thing I'd caution is that DSDOC4x obviously needs to start to "stabilize" as we near our first 4.0 Release Candidate. But, before then, we can play around as long as we work towards stabilization
[20:59] <tdonohue> We can also copy the space for major experiments as needed. The only problem there is that there's no way to "sync" up changes between two spaces...so we'd need to sync anything *manually* as needed
[20:59] <bram-atmire> well, very concretely:
[20:59] <bram-atmire> i think the "usage" vs "administration" idea is quite a good starting point
[21:00] <bram-atmire> the top nodes in the docs right now are:
[21:00] <bram-atmire> DSpace 4.x documentation
[21:00] <bram-atmire> with one sub node
[21:00] <bram-atmire> DSpace System Documentation
[21:00] <bram-atmire> and that subnode contains all the other pages
[21:00] <bram-atmire> so I want to add a Usage page on the level of "DSpace System Documentation"
[21:00] <bram-atmire> and an Administration page
[21:01] <bram-atmire> and page by page move some of the older pages in one of those nodes
[21:01] <bram-atmire> and then we can talk about the stuff that remains left under the current node, "DSpace System Documentation"
[21:01] <helix84> the benefit of that approach is that any links to particular pages will still work
[21:01] <mhwood> Sounds good.
[21:01] <bram-atmire> that was what I was hoping
[21:02] <helix84> one concern, though
[21:02] <helix84> say, we'll have a page called Introduction in both Admin and User guide, there would be a name clash
[21:03] <helix84> the same functionality can be described from both aspects, so there might be several such clashes
[21:03] <tdonohue> Sounds reasonable to me, bram-atmire. Though, helix84 is correct, we need to avoid "name clashes"... You cannot have two pages with the exact same name under the same Wiki Space.
[21:04] <tdonohue> But, that's a problem we can solve by changing names slightly, e.g. "Embargo Usage" and "Embargo Admin/Setup"... or something like that
[21:04] <tdonohue> And it's not a new problem..it's one we have already. We have to avoid name clashes
[21:05] <tdonohue> But, the idea of creating new top level pages and moving stuff around is a good one. It might help us determine if there are just "two categories" of top-level docs (Usage vs. Admin), or if there are more than that.
[21:05] <mhwood> It sounds like a plan. And I have to go. Thanks, all!
[21:06] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:07] <hpottinger> is it possible to refactor confluence offline? I know it will export to Word, can you round-trip changes?
[21:07] <tdonohue> If we want something like a "shared" Preface/Introduction....we could also just add "Admin Guide" and "Usage Guide" as child pages of the "DSpace System Documentation" page...that way they are essentially just "sections" of that same document, which share the same Preface & Intro
[21:07] * helix84 shudders
[21:07] * hpottinger hands helix84 a blanket
[21:08] <tdonohue> hpottinger. You can only export & edit *individual pages*. Word doesn't understand a hierarchy of docs, so there's no way to refactor the hierarchy of confluence pages from Word.
[21:08] * helix84 hides his face into the blanket
[21:08] <tdonohue> But, luckily, moving pages around in the Confluence Hierarchy actually isn't too horrible. It's mostly drag & drop, IIRC
[21:09] <helix84> ha ha, what I see is almost never what I get. YMMV.
[21:10] <hpottinger> it's a pity that using Confluence for docs tethers you to the network
[21:11] <helix84> https://confluence.atlassian.com/display/DISC/Offline+Confluence+Access
[21:11] <kompewter> [ Offline Confluence Access - Confluence User Community - Atlassian Documentation ] - https://confluence.atlassian.com/display/DISC/Offline+Confluence+Access
[21:11] <tdonohue> Ok..well, in any case, it sounds like we have a direction bram-atmire proposes to try. We can always move around the "DSpace Administration" and "DSpace Usages" nodes within the hierarchy later on if needed...the important part is to start the refactoring into these two "sections".
[21:12] <helix84> one thing that almost never works for me are links to anchors within pages
[21:12] <helix84> Page#anchor
[21:12] <bram-atmire> Doing it now as we speak, hope that this won't cause to many headaches
[21:13] * tdonohue notices were are obviously over-time here... no more "official" topics for today, but I'll hang around for this discussion a bit longer.
[21:14] <tdonohue> helix84: anchors within pages still work fine.. they only "break" when you change the text that you anchored to (as when the text of a heading changes, the anchor name changes). So, usually, I try to avoid using them *too much* as they are more easily broken than links between pages (Which Confluence will try to fix for you automatically)
[21:15] <bollini> just updated the PR 288 https://github.com/DSpace/DSpace/pull/288
[21:15] <kompewter> [ DS-1561 build.properties breaks no-auth SMTP by abollini · Pull Request #288 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/288
[21:16] <bollini> use the configurationservice instead of the configurationmanager resolve the issues with empty value. I want to merge the PR to solve similar issue with alert.recipient
[21:18] <helix84> tdonohue: OK, say I want to link to "Functional+Overview#FunctionalOverview-AuthenticationAuthentication" and I want the link to say "Authentication". How do I fill out the fields?
[21:19] <helix84> and which tab: Search? Advanced? Web Link (ugh)?
[21:20] <tdonohue> helix84: to create a page anchor, you just do this: (1) Insert Link, (2) Go to "Advanced" tab, (3) Type in [Page Title#Heading Text]. So, for your example it'd be "Functional Overview#Authentication" (Notice you keep any spaces in the page title or heading text!)
[21:21] <tdonohue> helix84: Docs on anchors are here: https://confluence.atlassian.com/display/CONF43/Linking+to+Pages#LinkingtoPages-LinkingtoanAnchororHeading
[21:21] <kompewter> [ Linking to Pages - Confluence 4.3 - Atlassian Documentation ] - https://confluence.atlassian.com/display/CONF43/Linking+to+Pages#LinkingtoPages-LinkingtoanAnchororHeading
[21:21] <helix84> tdonohue: OK, I did that (with a space). This is the red link it produced: https://wiki.duraspace.org/pages/createpage.action?spaceKey=DSPACE&title=Functional+Overview&linkCreation=true&fromPageId=19006494
[21:21] <kompewter> [ Log In - DuraSpace Wiki ] - https://wiki.duraspace.org/pages/createpage.action?spaceKey=DSPACE&title=Functional+Overview&linkCreation=true&fromPageId=19006494
[21:24] <helix84> oh, got it now
[21:24] <hpottinger> bollini, PR 288 looks great, but you'll probably want to run it by mhwood
[21:25] <bollini> why? it is very trivial and not related to the EmailService
[21:25] <bollini> I'm just waiting for Travis CI to complete
[21:26] <helix84> there's one more gotcha: "Functional Overview#Authentication" links to ToC item, whereas "Functional Overview#AuthenticationAuthentication" links to the actual chapter
[21:27] <hpottinger> bollini, I just wasn't part of the discusscusion to begin with, I'm more of an interested bystander :-) But if Travis says it compiles, and you say it works, it's good enough for me :-)
[21:28] <bollini> Travis says yes: https://travis-ci.org/DSpace/DSpace/builds/10469678
[21:28] <kompewter> [ Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community ] - https://travis-ci.org/DSpace/DSpace/builds/10469678
[21:28] <hpottinger> push the button, Max!
[21:29] <bollini> ok merged. Good night! See you tomorrow
[21:29] <hpottinger> I gotta go, too, night all!
[21:30] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has left #duraspace
[21:30] * bollini (~chatzilla@95.235.208.246) Quit (Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812])
[21:37] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
[21:58] <bram-atmire> byebye, first attempt done: https://wiki.duraspace.org/display/DSDOC4x/DSpace+4.x+Documentation
[21:58] <kompewter> [ DSpace 4.x Documentation - DSpace 4.x Documentation - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSDOC4x/DSpace+4.x+Documentation
[21:59] <bram-atmire> will send an email to dspace-commit tomorrow with an outline of what has been moved/changed so far
[21:59] * bram-atmire (~bram@94-225-35-170.access.telenet.be) Quit (Quit: bram-atmire)
[22:11] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.