Timestamps are in GMT/BST.
[6:42] -sendak.freenode.net- *** Looking up your hostname...
[6:42] -sendak.freenode.net- *** Checking Ident
[6:42] -sendak.freenode.net- *** Found your hostname
[6:42] -sendak.freenode.net- *** No Ident response
[6:42] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:42] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:42] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[12:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:39] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[12:46] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[12:49] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[15:22] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) Quit (Quit: barmintor)
[17:04] * mdiggory (~mdiggory@38.109.41.15) has joined #duraspace
[17:14] * mdiggory (~mdiggory@38.109.41.15) Quit (Quit: Colloquy for iPad - http://colloquy.mobi)
[17:31] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) Quit (Read error: Connection reset by peer)
[17:49] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[18:55] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:23] * barmintor (~ba2213@dyn-butler-158-112.dyn.columbia.edu) has joined #duraspace
[19:30] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[19:45] * mhwood (~mhwood@adsl-99-130-174-7.dsl.ipltin.sbcglobal.net) has joined #duraspace
[19:48] <tdonohue> Hi all. Reminder that we have a DSpace Developers meeting at the top of the hour (in about 12mins): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-14
[19:49] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:00] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:01] <tdonohue> Hi all. It's time for our weekly DSpace Developers Mtg: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-14 (Folks in USA & Canada will notice it seems an hour later, but it's just Daylight savings time messing with you)
[20:01] <kompewter> [ DevMtg 2012-03-14 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-03-14
[20:01] <tdonohue> we'll kick off with JIRA reviews: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-958+ORDER+BY+key+ASC
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-958 ] - [#DS-958] Port XMLUI to Cocoon 3.0 - DuraSpace JIRA
[20:01] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-958+ORDER+BY+key+ASC
[20:01] <tdonohue> starting with DS-958
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-958 ] - [#DS-958] Port XMLUI to Cocoon 3.0 - DuraSpace JIRA
[20:02] <tdonohue> looks like this is a "placeholder" of sorts. And I'd be a bit hesitant to move to Cocoon 3.0 until it's out of "alpha" stage (and who knows how long that will be)
[20:02] <mhwood> Ha, I ranted on cocoon-users just last week that (according to the cocoon site) 3.0 is *still alpha* after four years and the latest release is still 2.2.0
[20:03] <tdonohue> did you get a response to the rant, mhwood?
[20:04] <tdonohue> Cocoon 3.0 has an "alpha warning": http://cocoon.apache.org/3.0/alpha-warning.html
[20:04] <kompewter> [ Alpha Warning ] - http://cocoon.apache.org/3.0/alpha-warning.html
[20:04] <mhwood> Well, it seemed to draw a bit of attention. Others were lamenting the low uptake of 3.0 and I strongly suggested that releasing it and updating the site would go a long way. There is interest in getting 3.0 out into the world but I don't know how long that will take.
[20:05] <tdonohue> ok. so, I'd suggest we copy & paste these notes to Ds-958 comments for now. I'm hesitant to touch on this any further until the Cocoon community gets closer to a 3.0 final.
[20:06] <tdonohue> Ds-958 Summary: Copy above discussion notes into ticket comments. "On Hold" for now as Cocoon 3.0 is still "alpha".
[20:06] <mhwood> I do think that 3.0 is getting all the attention there is. There are seemingly immortal bug reports against 2.2 *with fixes* that never get taken up, and folks are passing around bits of lore and loose patches to make 2.2 work.
[20:07] <mhwood> So, when there is a reasonably stable 3.0 we should strongly consider moving to it just to get some interest in any bug reports we file.
[20:07] <tdonohue> makes perfect sense. I'd agree. (just nervous about jumping over to something still in "alpha")
[20:08] <mhwood> Me too, I recommend against depending on 3.0 alpha.
[20:08] <hpottinger> mhwood: is there anything we can do to help the Cocoon folks elect to release an official version 3?
[20:09] <mhwood> Dunno. I would if I could, but I don't know the inwards of Cocoon well at all.
[20:09] <mhwood> Those who feel able to help should ask on the Cocoon lists, or just look over the bug reports and start filing patches I guess.
[20:10] <mhwood> I got a sense that there are just not enough hands to make rapid progress.
[20:10] <tdonohue> yea, it looks like they are still working on 3.0, based on this: http://cocoon.apache.org/3.0/changes-report.html (so, it might be a matter of needing "more hands" like mhwood suggests)
[20:10] <kompewter> [ Changes Report ] - http://cocoon.apache.org/3.0/changes-report.html
[20:11] <tdonohue> (notice that there's very few developer names that appear in that changes report -- only about 4-5 overall in recent years)
[20:11] <hpottinger> I don't have any "spare cycles" but I can at least poke around on their site and mail list, keep an eye out for anything I can help out with
[20:12] <tdonohue> in any case, we should probably set this ticket aside and move on for now.
[20:12] <tdonohue> next up, DS-962
[20:12] <kompewter> [ https://jira.duraspace.org/browse/DS-962 ] - [#DS-962] SubmissionProcess Configuration - DuraSpace JIRA
[20:13] <mhwood> A popular idea and it appears that there is already some code.
[20:13] <tdonohue> oh, this is the GSoC2011 project, mentored by mdiggory. Not sure what state the final code was in? (and mdiggory isn't around today)
[20:14] <tdonohue> +1 to the idea. The code itself though might still need either further review or 'cleanup'
[20:14] <mhwood> I agree, +1 idea.
[20:15] <aschweer> just scrolling to the patch looks like there are a bunch of unrelated changes in there too
[20:16] <tdonohue> yea, patch looks a bit "messy" and could use some cleanup.
[20:16] <aschweer> plus I guess it'd be good to have someone look over this who's familiar with the configurable submission stuff
[20:16] <aschweer> configurable workflow, sorry
[20:16] <tdonohue> Anyone here interested in this work? Just wondering if anyone wants to try and get this running and touch base with mdiggory & guarav (if he's still around and willing)
[20:18] <tdonohue> ok, hearing no volunteers.
[20:18] <tdonohue> Ds-962 Summary: suggest we touch base with mdiggory about status of this work via the ticket. Needs a volunteer (or two) to possible shepherd it forward
[20:19] <tdonohue> one more, just cause mhwood is here: DS-966
[20:19] <kompewter> [ https://jira.duraspace.org/browse/DS-966 ] - [#DS-966] Make the testing framework available to all projects, not just dspace-api - DuraSpace JIRA
[20:19] <tdonohue> anything you want us to look at yet, mhwood? Or is this just a placeholder for now?
[20:20] <tdonohue> Ds-966 gets a big +1 from me. we just need someone with some cycles to look at it.
[20:20] <mhwood> I guess I should assign this one to myself, since I've done some work on it already. Phase I is actually in trunk: making the test-data directory tree.
[20:21] <tdonohue> cool, yea I do recall seeing that. definitely assign it to yourself then, so that we can track who is working on it. Also let us know when you need help / more eyes / testers
[20:22] <mhwood> To go beyond that needs some way to automatically augment the DSpace configuration. I wrote a Maven plugin that can do this but haven't got it into Maven Central so nobody else could use it.
[20:22] <hpottinger> I've mentioned it before, but I'd be interested in helping with this
[20:22] * helix84 (a@195.113.97.174) has joined #duraspace
[20:22] <mhwood> Recently I've been looking at tackling the configuration problem a different way: convert the authority control configuration to Spring. This turns out to need to convert the plugin configuration too.
[20:23] <tdonohue> mhwood -- if you want someone to test the Maven plugin you wrote, you can just post it up somewhere (JIRA or email) and we can do a manual 'mvn install' (i.e. you don't have to wait for it to get to Central)
[20:23] <hpottinger> (clarification, "this" refers to 966, not with Maven Central)
[20:23] <mhwood> I need to write up my thoughts about the Springification stuff.
[20:23] <aschweer> mhwood: I'd definitely be interested in hearing about that
[20:24] <aschweer> I ran into a few things with configuring event listeners recently that could probably be improved too
[20:24] <aschweer> ("that" in my case being the Springification, but Ds-966 sounds interesting too)
[20:24] <tdonohue> +1 to springification of configs (where it makes sense to -- and I think the authority control stuff likely does make sense for that)
[20:24] <mhwood> I will write up the Spring stuff as it stands and make some noise on the dev list about the Maven stuff.
[20:25] <tdonohue> sounds like a good plan
[20:25] <mhwood> The plugin is actually in SVN too -- I just need to remember where.
[20:25] <KevinVdV> mhwood: for the spring configuration, you might want to look @ discovery it is also configured by spring.
[20:25] <tdonohue> haha :) sorry. Yea, sometimes it's hard to remember exactly where things are in SVN. Hopefully we can clean that up a bit more in GitHub
[20:26] <mhwood> http://scm.dspace.org/svn/repo/tools/maven/FileWeaver/
[20:26] <kompewter> [ repo - Revision 6957: /tools/maven/FileWeaver ] - http://scm.dspace.org/svn/repo/tools/maven/FileWeaver/
[20:27] <tdonohue> ok, so sounds like we have a plan for moving forward with Ds-966 (on -dev list) and some more related springification discussions.
[20:28] <tdonohue> Might as well close the JIRA discussion for today, and move on to other topics
[20:28] <tdonohue> First up, GitHub Migration: https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub (I notice PeterDietz just sent an email to dspace-devel & dspace-commit asking some questions as well)
[20:28] <kompewter> [ Migration to GitHub - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Migration+to+GitHub
[20:29] <PeterDietz> hi
[20:29] <tdonohue> Peter & I had the same question (which I have in the agenda too). There was discussion (in #dspace) earlier this week about just leaving the DSpace/DSpace Github as-is: https://github.com/DSpace/DSpace
[20:29] <kompewter> [ DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace
[20:29] <PeterDietz> 1) Should we stick with the existing Github.com/dspace/dspace repository, or should we reimport (a fresh git svn clone) so that we can use the author mapping to make old commits point to a user's GitHub profile? By pushing that change, it would make the current repo incompatible with anyone who has forked it, as the reimport would have completely different commitID's.
[20:30] <PeterDietz> 2) What should we do about languages? We have dspace-xmlui-lang and dspace-api-lang I don't imagine that people like having to manage two separate language files. So would we want to consolidate that into a single project? If so, anyone up to doing the work for that refactoring? Where would messages/language extensions for modules fit?
[20:31] <tdonohue> Regarding Peter's #1 question. I'm starting to lean towards just leaving https://github.com/DSpace/DSpace as-it-is. This would mean that we would *not* map our SVN user commits to GitHub (for this project). But, it'd be less detrimental to folks already using GitHub (as Peter describes)
[20:31] <kompewter> [ DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace
[20:31] <mhwood> 1) I don't have any clones that I couldn't just throw away and redo. I'm uncertain about how we want to move revisions around anyway.
[20:32] <aschweer> mhwood +1 -- I can re-do my clones too
[20:32] <PeterDietz> For (1 - re git svn clone the dspace/dspace), I'm not in favor of doing such a re git-cloning. Not that there is a huge amount of forks already using the github fork, I just don't think it would help by much to redo it
[20:33] <PeterDietz> The main gain would be that your old commits will link to your GitHub profile page, as opposed to just have your svn-user-name
[20:33] <aschweer> I guess the question is what does it buy us -- if it's just the association with the user's GitHub profile, then I can definitely live without that (but then I don't have many commits anyway)
[20:33] <tdonohue> To clarify. If we wipe out the DSpace/DSpace GitHub & redo it, it mostly just affects those folks who have "forked" it. namely these people/institutions: https://github.com/DSpace/DSpace/network/members
[20:33] <kompewter> [ Network Members · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/network/members
[20:35] <PeterDietz> It might also break any url links from old dspace-tech emails. Since they often have a git commit hash in the url
[20:36] <tdonohue> Are there any other GitHub "stats" that are affected if we don't do this mapping? As developers is it beneficial to have these old commits associated with our GitHub accounts cause it shows our activity over time? Or is this really not adding anything to the "GitHub experience"?
[20:37] <mhwood> We could just post the mapping somewhere, for anyone who needs to assign blame and can't work it out from the old/new names' similarities.
[20:38] <tdonohue> yea. I'm ok with that. I'm definitely not saying we need to redo this mapping. Just trying to understand the full pros/cons to this decision
[20:39] <tdonohue> (And I think there is a very big "con" in that all these people who have forked this repo will have a major pain if we delete it and redo it: https://github.com/DSpace/DSpace/network/members)
[20:39] <kompewter> [ Network Graph · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/network/members)
[20:39] <mhwood> I'd consider the revision chains to be more important information than the personalities, especially since we won't *lose* the personalities.
[20:41] <PeterDietz> My personal vote is that being able to click on an old commit and have it link to my github profile isn't worth that much
[20:41] <PeterDietz> New commits (made directly in Git) will link to your github profile (provided you have your email address configured properly)
[20:42] <tdonohue> PeterDietz -- if that's the only "pro" then I agree. Which is why I was trying to determine if there are any other "pros" to redoing the repo altogether (i.e. if GitHub keeps "stats" on developers, or anything)
[20:42] <PeterDietz> perhaps, we would gain that: https://github.com/DSpace/DSpace/contributors has a big zero, since there are zero mapped authors
[20:42] <kompewter> [ Contributors · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/contributors
[20:43] <hpottinger> IMHO, breaking links in archived messages on dspace_tech links isn't worth it, either
[20:45] <PeterDietz> IT would have been cool to have legacy developer stats, So I could compete against some of the original developers (rtansley et al)
[20:45] <mhwood> If anyone has work he'd be reluctant or unable to redo, I'd say leave things as they are and we'll deal with the personalities when we need to.
[20:45] <PeterDietz> by personalities you mean committer name+email+link ?
[20:45] <tdonohue> Ok, so sounds like those in attendance are arriving at a consensus around the "path of least resistance" (which is to just leave it as-is, unless we determine a real strong reason why we need to redo things)
[20:46] <mhwood> We can dredge stat.s out of SVN and post them somewhere, since they'll be static. Roll them into combined SVN/Git stat.s if there is an interest in such reports.
[20:46] <hpottinger> +1 tdonohue
[20:46] <mhwood> +1
[20:46] <tdonohue> +1 from me as well
[20:46] <mhwood> Yes, personalities = name and email.
[20:46] <aschweer> just cause I have no clue about the mapping really -- this wouldn't buy us the "personalities" without re-doing? http://help.github.com/change-author-info/
[20:46] <kompewter> [ Help.GitHub - Change author info ] - http://help.github.com/change-author-info/
[20:47] <tdonohue> aschweer -- notice the "big bold warning" at the top. This essentially is a form of "redo" as it breaks your GitHub repos "history"
[20:47] <PeterDietz> aschweer: it would basically be doing that. Rewriting all commits, or deleting entire repo with an author-map in hand, are about equal in incompatibility
[20:48] <aschweer> ah of course, I've only used it on a non-shared repo, didn't think of the commits
[20:48] <aschweer> nevermind me then, I agree with everyone else
[20:49] <PeterDietz> I'm +1 leave as-is,
[20:50] <tdonohue> Ok, sounds like a consensus on that then. I'll email -commit about this decision after the meeting (just so others have an opportunity to voice an opinion, if they feel the need)
[20:50] <hpottinger> maybe a fun side project: script up an official "leaderboard" that meshes old SVN stats with new GitHub stats
[20:51] <PeterDietz> cool, then my question #2, what to do about dspace-api-lang and dspace-xmlui-lang
[20:52] <tdonohue> RE: the language packs. I think we need to move them over "as-is" right now (otherwise it's a *lot* of code to rewrite). But, I wonder if we can create a single DSpace/dspace-lang-packs GitHub Project, and put both in the same project? (in anticipation of maybe merging them together in future)
[20:52] <mhwood> If merging them is more than 1-2hr. work then I think it would have to be a separate issue. Don't want to hold up the migration for this, though it could be worthwhile.
[20:52] <mhwood> Oh, I see.
[20:53] <mhwood> Actuall, I think that dspace-api-lang needs split into really-dspace-api-lang and dspace-jspui-lang
[20:55] <tdonohue> yea, I agree. But, I again think that's a separate issue. I'd like to keep "reworking language packs & how we are doing them" separate from "move language packs to GitHub". Otherwise the latter will be waiting for a while.
[20:55] <PeterDietz> I agree, its gonna take lots of work to consolidate languages across the board (if that is the intention)
[20:56] <tdonohue> "consolidate language packs" is a good idea (maybe even for 3.0), but it should happen *after* moving to GitHub
[20:56] <tdonohue> (in my opinion)
[20:56] <mhwood> It makes sense to have a single distinct place for language work. It takes specialized knowledge of human languages and not much coding knowledge.
[20:56] <PeterDietz> It sounds safe to migrate them as seperate modules/repos, and do the refactoring afterwards
[20:57] <tdonohue> PeterDietz -- what do you think about combining them into one repo though (named "DSpace/dspace-lang-packs") just to keep them in one place? Just curious if there'd make it easier on folks to find them.
[20:58] <tdonohue> By "combining" into one repo, I mean that the repo "DSpace/dspace-lang-packs" would have two folders: 'dspace-api-lang' and 'dspace-xmlui-lang'
[20:59] <tdonohue> But, then again, I guess if we do this, then we'd probably need to do some Maven rework -- so, maybe I'm now arguing against my idea :)
[20:59] <mhwood> The artifact coord.s wouldn't change, would they?
[21:00] <PeterDietz> There is some magic available to do these things. Either through filter-branch, submodules, subtree merge, or through just combining two unrelated repositories
[21:01] <tdonohue> mhwood - No. I guess it'd jut be a matter of whether we'd want to start "releasing them together" if they are in one GitHub project. (Currently they are independent of each other)
[21:01] <PeterDietz> Because one might want to be able to move message keys from one to the other, and track those changes
[21:01] <tdonohue> true. PeterDietz. That argues to have them "closer together"
[21:03] <mhwood> They could still be released separately, no? Just go down into whichever *Maven* project subdirectory and 'mvn release:whatever'?
[21:03] <tdonohue> mhwood - yea. that's true. They could still be released separately by running 'mvn release' from the subdirectories
[21:03] <mhwood> Maven knows where we keep the code, but I don't think it cares.
[21:04] <PeterDietz> So what being project independent. If the webmvc project has language / messages, should those be pumped into dspace-common-languages ?
[21:04] <mhwood> To clarify: I don't think this is one of those Maven-will-fight-you-to-the-death issues.
[21:05] <PeterDietz> or, dspace-lang-packs will have /dspace-api /xmlui and /webmvc directories?
[21:05] <tdonohue> PeterDietz -- I think that's a great question, but that belongs into the "we need to rethink how we are doing language packs", rather than "move language packs to GitHub".
[21:06] <PeterDietz> So, putting dspace-api-lang and dspace-xmlui-lang into the same repo might be premature
[21:06] <PeterDietz> ...though we'd like to keep things simple
[21:07] <tdonohue> yea, in my mind 'dspace-lang-packs' was more about keeping things simple, if possible. I wasn't sure if we really wanted to start creating a new GitHub repo for *every* Maven module that we have.
[21:08] <PeterDietz> so more of a namespace.. I'm not sure there is any way to have a hierarchy of projects. I think it ends up becoming a massively long list of projects, where rarely used things sink to the bottom
[21:09] <PeterDietz> p.s. I've added a documentation page on xmlui themes in use by OSU KB.. (in case anyones missed it) : https://github.com/osulibraries/DSpaceOSUKB/wiki/XMLUI-Customizations-to-Themes
[21:09] <kompewter> [ Interesting Themes in use by Ohio State University Knowledge Bank · osulibraries/DSpaceOSUKB Wiki · GitHub ] - https://github.com/osulibraries/DSpaceOSUKB/wiki/XMLUI-Customizations-to-Themes
[21:09] <tdonohue> correct. in that scenario, 'dspace-lang-packs' is almost acting as a "namespace" or "grouping" of similar Maven projects -- the first two being 'dspace-api-lang' and 'dspace-xmlui-lang'
[21:10] <tdonohue> How about this: I'll take the lead in investigating the "plausibility" of creating a 'dspace-lang-packs' project with *both* dspace-api-lang and dspace-xmlui-lang contained in it. I can report back to dspace-commit on what I find out.
[21:10] <tdonohue> and if it "fails" then I'll just delete 'dpace-lang-packs' from GitHub, and move them over into separate GitHub repos
[21:11] <tdonohue> (PeterDietz -- I may ping you on some of this though, especially if you have any experience on merging two SVN histories into a single GitHub repo)
[21:12] <mhwood> TBH I'm less concerned with which way to do this than with the question of when I should start using DSpace@GitHub in earnest.
[21:15] <PeterDietz> it looks like to migrate the lang modules we'll just need a few authors:
[21:15] <PeterDietz> peterdietz:dspace-api-lang peterdietz$ ../authors-generate.sh .
[21:15] <PeterDietz> cjuergen = NAME <USER@DOMAIN>
[21:15] <PeterDietz> kshepherd = NAME <USER@DOMAIN>
[21:15] <PeterDietz> mdiggory = NAME <USER@DOMAIN>
[21:15] <PeterDietz> peterdietz = NAME <USER@DOMAIN>
[21:15] <PeterDietz> robintaylor = NAME <USER@DOMAIN>
[21:15] <PeterDietz> tdonohue = NAME <USER@DOMAIN>
[21:16] <PeterDietz> and all of these people have github users
[21:16] <tdonohue> mhwood: Currently we should still be using SVN (for main codebase), as the SVN->GitHub sync is still enabled. But, as soon as we validate 100% (on dspace-commit) that we will NOT redo 'https://github.com/DSpace/DSpace', then we could actually switch that main 'trunk' work over to GitHub entirely
[21:16] <PeterDietz> I'm going to for the next 15 or so minutes, migrate these two (api-lang and xmlui-lang) projects into github
[21:17] <tdonohue> PeterDietz: Ok, if you want to give it a try, feel free :) Are you going to move them together into 'dspace-lang-packs' or just migrate them separately?
[21:17] <mhwood> Also how the work flows. Are we generally agreed that one forks a project at GitHub, clones that to work on it, pushes back work that's ready to be seen/shared, and then *something happens* to get finished work into DSpace/*?
[21:18] <PeterDietz> tdonohue: I'd like to get some momentum behind the lang-packs for a certain direction to head before making any "structural" changes
[21:18] <PeterDietz> I can make a third repository that sort of "glues" these two independent projects into one place
[21:19] <tdonohue> mhwood -- good question. I think we need to determine our GitHub workflow. Fedora Committers went through this same discussion, and developed their own "Git Best Practices" https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[21:19] <kompewter> [ Git Guidelines and Best Practices - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[21:19] <tdonohue> we will want to develop our own GitHub best practices (which could be similar to Fedora's or entirely our own -- it's up to us)
[21:22] <tdonohue> mhwood: admittedly, I need to respond to the thread you started on dspace-devel (thanks for that). Hopefully we can start to figure out a GitHub workflow that will work well for all of us
[21:22] <mhwood> Fedora's document looks like a good starting point. And I'm going to be pushy about the line-endings stuff, which I hadn't thought of. :-)
[21:23] * tdonohue notes we are obviously way way over time. Sorry. GitHub is obviously a very "big" topic.
[21:24] <tdonohue> Fedora also has a "Quick Start Guide" for their developers, based on their best-practices: https://wiki.duraspace.org/display/FCREPO/Git+Quick+Start+Guide
[21:24] <kompewter> [ Git Quick Start Guide - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Git+Quick+Start+Guide
[21:25] <tdonohue> One thing to note though. I *believe* Fedora developers do *not* tend to fork their own project. Instead they work directly in the main GitHub project itself (and just create a new branch).
[21:26] <mhwood> I noticed that. Will have to think about it. Something to discuss in the coming days.
[21:26] <tdonohue> So, that is one decision we will need to make. Do we like Fedora's workflow? Do we want to have our developers always *fork* (and work in their public fork)?
[21:27] <helix84> Branching works only for commiters, other contributors would still have to fork. Is there a reason to make such a distinction?
[21:27] <PeterDietz> dspace-xmlui-lang is looking good
[21:27] <PeterDietz> all authors mapped: https://github.com/DSpace/dspace-xmlui-lang/graphs/impact
[21:27] <kompewter> [ Impact · DSpace/dspace-xmlui-lang · GitHub ] - https://github.com/DSpace/dspace-xmlui-lang/graphs/impact
[21:28] <tdonohue> Ok. I unfortunately need to move into "lurking" for a bit. So, I'm going to "close" the Official meeting. But, folks are welcome to stick around and continue the discussion.
[21:29] <PeterDietz> the distinction between svn-era committers, and github-era committers is somewhat interesting
[21:29] <aschweer> helix84: making fork the default for everyone sounds good to me. but I haven't had time to think this through properly.
[21:29] <PeterDietz> svn-era, you are literally the only ones who can write/commit to the code
[21:29] <tdonohue> One last thought to add around 'forking' (which helix84's comment reminded me of) -- on *benefit* to forking, is that it can be a process that *every* commit gets a review process (even a simple one)
[21:29] <PeterDietz> github-era, any member of the public can fork/commit/pull-request, and if approved and merged, their work gets pulled in
[21:30] <aschweer> and committer = someone who can approve a pull request into the "official" repo
[21:30] <tdonohue> i.e. if all developers (including committers) had to *fork* the main codebase, then everyone would be required to submit a "pull request" in order to have their code reviewed (likely by someone else) before it was applied
[21:30] <PeterDietz> so a github-era committer, means your more-or-less grandfathered in to be a member of the github-dspace team, who can accept pull-requests
[21:30] <helix84> There's a pro for commiters forking: you could do rebase before commiting and have much clearer logs in "trunk" project
[21:31] <aschweer> also, committers forking would mean no issues with different configuration settings all over committers' branches in the main repo
[21:31] <helix84> I agree with tdonohue's review point - another pro for forking
[21:31] <PeterDietz> I suppose there might be a _few_ times where I would directly commit/push to DSpace/DSpace, but in most instances, I'd want to test my changes, and get someone's feedback, so I'll have a fork at peterdietz/DSpace
[21:32] <hpottinger> I personally like the idea of working more publicly, it's one of the main reasons to move to GitHub, yes?
[21:32] <aschweer> PeterDietz: which means we should think about what are the times where you can directly push to DSpace/DSpace -- eg fixing typos in comments etc
[21:32] <aschweer> hpottinger +1
[21:33] <PeterDietz> social coding
[21:33] <tdonohue> PeterDietz: yea. I would agree there would likely be some exceptions where we want to directly commit/push to DSpace/DSpace (main codebase). Like aschweer says, typos are a good example
[21:33] <mhwood> Using a personal fork sounds best. I just want to know what the norm will be.
[21:33] <helix84> hpottinger: luckily, you can still have a local repo with messy history, then rebase it to clean up history before you push it to your public repo and only then make a pull request
[21:34] <tdonohue> I also admittedly lean towards having a personal public fork (and work publicly). I think it'd also be a good thing to actually encourage us all to also have our code reviewed by someone else (when possible, and when the change isn't an obvious one).
[21:35] <hpottinger> helix84: you don't know the half of it, you should see my desk, it's a disaster :-)
[21:35] <aschweer> tdonohue +1
[21:35] <KevinVdV> Needs to run until later
[21:35] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- Now with extra fish!)
[21:36] <tdonohue> In any case, we need to get others "on board" with these ideas. So, we should move discussion to dspace-devel thread and start to develop our own "best practices"
[21:36] <mhwood> Yes.
[21:36] <helix84> I don't want to interrupt the important GitHub conversation, but I've been waiting to ask a different question, so if you could just answer me asynchronously...
[21:37] <PeterDietz> mdiggory's been refactoring / consolidating maven projects, so thats worth a peek https://github.com/mdiggory/DSpace/commits/maven-project-consolidation?
[21:37] <kompewter> [ Commit History · mdiggory/DSpace · GitHub ] - https://github.com/mdiggory/DSpace/commits/maven-project-consolidation?
[21:37] <helix84> ...why are there communities and collections in DSpace? Why not just one "category" that can be nested?
[21:37] <helix84> It may sound like a noob question, but it's been bothering me for a long time
[21:38] <tdonohue> helix84: the only reason I know of is "that is how DSpace was originally designed back in 2002 and it's never been changed"
[21:38] <PeterDietz> legacy, its been in the data model since forever
[21:38] <mhwood> There's occasional talk of reworking that.
[21:38] <PeterDietz> it certainly would be much better to consolidate communities and collections into just collections, which can nest
[21:39] <helix84> I may have some other suggestions regarding "Metadata for all" that would also require breaking the schema. Could we consider some bigger schema changes for 3.0?
[21:39] <tdonohue> Yea, this is a popular topic. I think many of us would like to consolidate communities & collections -- but that is a large project.
[21:39] <mhwood> That's what .0s are for.
[21:40] <mhwood> 'twas done in the 2.0 project.
[21:40] <mhwood> But not backported, obviously.
[21:40] * PeterDietz dspace-api-lang is done -- https://github.com/DSpace/dspace-api-lang/contributors
[21:40] <kompewter> [ Contributors · DSpace/dspace-api-lang · GitHub ] - https://github.com/DSpace/dspace-api-lang/contributors
[21:41] <helix84> mhwood: could you give me a link?
[21:41] <tdonohue> helix84: yea, we could definitely make large schema changes for 3.0. The idea of "Major releases" (.0's) are that we can make larger changes as needed. It's just a matter of finding volunteer developers to write the code, etc.
[21:41] <helix84> tdonohue: I'm not really a Java programmer, but I have suggestions on how to change schema if that's worth anything
[21:41] <mhwood> I wasn't involved in 2.0 but there will be leads on the wiki. The code is in SVN, yes?
[21:42] <tdonohue> mhwood is correct. The DSpace 2.0 "Prototype" did combine Communities & Collections into "Containers" (I think that's the name they used). That old prototype is up at: https://wiki.duraspace.org/display/DSPACE/DSpace+2.0
[21:42] <kompewter> [ DSpace 2.0 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+2.0
[21:43] <tdonohue> helix84: you are more than welcome to suggest changes (we welcome all community suggestions). It's just a question of whether we'll be able to get them done before 3.0 (as obviously we need to find a volunteer developer or two to actually make the changes suggested) :)
[21:44] <tdonohue> but, sometimes the act of suggesting changes can also help us to locate interested developers.
[21:46] <helix84> sure, I'll describe it in Jira
[21:47] <helix84> On a different note, I'd like to reserve a slot near the end of next DevMtg, there's a patch we'd like to contribute and I'd like to find a sponsor and reviewers for it.
[21:49] <PeterDietz> helix84: Any chance you'd want to be the guinea pig and try to make your patch on github, and send a pull request ahead of the meeting?
[21:49] <helix84> I still have to prepare the documentation and file a ticket with the patch
[21:49] <helix84> sure, I can
[21:50] <helix84> that brings us back to git workflow - will a pull request be a replacement for a ticket?
[21:50] <helix84> or are there issues where one or the other is preferable?
[21:50] <aschweer> I'd think we'd still want a Jira ticket, but with a link to the pull request instead of a patch?
[21:51] <PeterDietz> one compelling reason to stick with Jira for tickets is so that for the 3.0 release, you can include that a bunch of issues were fixed in that release, by patrolling Jira.
[21:51] <helix84> PeterDietz: you mean in the release notes?
[21:52] <PeterDietz> (For the release notes exactly)... and confluence makes that all very easy. We might be able to find some type of GitHub issues widget for the future (if we find github issues / pull requests) to be the way of the future
[21:52] <tdonohue> We'll still want a JIRA ticket to describe the change. But, if you likely could just link to a "pull request" rather than generating a patch.
[21:52] <helix84> OK, Jira ticket + with link to pull request it is
[21:52] <mhwood> Yes, best place for contributions (thank you!) is to attach to a Jira ticket. I don't think you have to wait for your number to come up; the weekly Jira review is to ensure that *every* ticket is looked at.
[21:53] <tdonohue> helix84: if there's a specific ticket you'd like to talk about, send me an email. I'd be glad to add it to the agenda in the coming weeks.
[21:53] <helix84> mhwood: I'm afraid whether you would get to it in the 3.0 cycle :)
[21:54] <helix84> It's just my opinion that tickets with patches should get priority for DevMtg reviews
[21:54] <mhwood> Yes. :-( But if something shouldn't wait, say so!
[21:54] <tdonohue> also, mhwood is correctly describing the process in these meetings. We'll gladly take a look at specific JIRA tickets (when requested). But, normally we dig through them in order (and we do have a backlog) in order to ensure every ticket is reviewed
[21:55] <helix84> I understand. I'll be prepared for next week.
[21:55] <PeterDietz> helix84: Any teaser as to what the issue is about?
[21:56] <helix84> it's a feature i requested a year ago, only now I got a student to actually implement it for me (I'm no Java programmer)
[21:56] <tdonohue> also, the "ticket with patches" getting priority is hard. Sometimes tickets actually have patches attached, and sometimes they link off to code elsewhere (e.g. the idea to link to a pull request). So, it's actually hard to determine which have "patches" without looking at all of them.
[21:57] * tdonohue has to head out. I'll catch up in the logs later. Bye all!
[21:57] <PeterDietz> assuming we'll ever clear through the Jira queue, tickets with patches, can be simple pull-requests
[21:57] <helix84> bye tim
[21:57] <PeterDietz> bye all. I gotta head home too
[21:57] <mhwood> Good time to sign off here as well. Thanks all!
[21:58] <helix84> thanks, see you
[22:00] * mhwood (~mhwood@adsl-99-130-174-7.dsl.ipltin.sbcglobal.net) has left #duraspace
[22:01] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[22:02] <kshepherd> PeterDietz: I edited the wiki page...
[22:02] <kshepherd> ~a week ago i think
[22:20] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has left #duraspace
[22:49] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.