Timestamps are in GMT/BST.
[0:58] * scottatm (~scottatm@adhcp218.evans.tamu.edu) Quit (Quit: scottatm)
[6:28] -brooks.freenode.net- *** Looking up your hostname...
[6:28] -brooks.freenode.net- *** Checking Ident
[6:28] -brooks.freenode.net- *** Found your hostname
[6:28] -brooks.freenode.net- *** No Ident response
[6:28] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:28] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:28] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:39] * Asger (~abr@nat.statsbiblioteket.dk) has joined #duraspace
[9:30] * Asger (~abr@nat.statsbiblioteket.dk) Quit (Read error: Connection reset by peer)
[9:31] * Asger (~abr@nat.statsbiblioteket.dk) has joined #duraspace
[11:45] * Asger (~abr@nat.statsbiblioteket.dk) Quit (Read error: Connection reset by peer)
[12:09] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:47] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) has joined #duraspace
[13:57] * scottatm (~scottatm@adhcp218.evans.tamu.edu) has joined #duraspace
[16:00] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has joined #duraspace
[16:01] * grahamtriggs (~Graham@host213-123-239-134.in-addr.btopenworld.com) has left #duraspace
[18:26] * renec (598ee8be@gateway/web/freenode/ip.89.142.232.190) has joined #duraspace
[18:28] * renec (598ee8be@gateway/web/freenode/ip.89.142.232.190) Quit (Client Quit)
[19:04] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) has joined #duraspace
[19:07] <KevinVdV> Hello everybody
[19:09] <KevinVdV> Is there anybody in here who has access to a DSpace 3.0 release candidate that is NOT the DSpace demo site ?
[19:49] <mhwood> KevinVdV: I have a 3.0 here. So far I've done very little with it other than get it running.
[19:54] <KevinVdV> mhwood could you perhaps attempt to submit an item & go to the second page & see if the controlled vocs are working (https://jira.duraspace.org/secure/attachment/12369/Controlled%20vocabulary%202012-02-19.png.jpg)
[19:55] <KevinVdV> This stuff appears broken on the demo but I cannot reproduce locally :(
[19:55] <tdonohue> Hi all, reminder that we have our weekly DSpace developers mtg in about 5 mins here. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-10-17
[19:55] <kompewter> [ DevMtg 2012-10-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-10-17
[19:57] <KevinVdV> mhwood: this is what I see on the dev: https://jira.duraspace.org/secure/attachment/12728/Screen%20Shot%202012-10-16%20at%2008.51.36.png
[19:57] <KevinVdV> dev == demo
[19:57] * helix84 (a@195.113.97.174) has joined #duraspace
[19:57] <tdonohue> KevinVdV -- if it's any help, we can give you commandline access to demo server (any committer can request it). (It's possible that something could be misconfigured there, or maybe the upgrade to 3.0 didn't work right)
[19:58] <tdonohue> actually, wait. I see you already have access KevinVdV ;)
[19:59] <KevinVdV> I have & I already checked the input forms they appear to be in order
[20:00] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) has joined #duraspace
[20:00] <mhwood> Mine behaves a lot like yours: when I select "Subject Categories", I get a popup with a tree of subjects. I can expand and collapse tree nodes, and when I select a leaf it gets set into the Subject: field.
[20:00] <tdonohue> ok, it's time for our weekly DSpace Devel Mtg. Today's agenda is at: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-10-17
[20:00] <kompewter> [ DevMtg 2012-10-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-10-17
[20:01] <KevinVdV> Ok thx mhwood this is all I needed to know (y)
[20:01] <tdonohue> KevinVdv -- just a brief note... I wonder if it's a Theme issue on demo server? Maybe something got messed up in the upgrade?
[20:02] * sands (~sandsfish@18.189.25.238) has joined #duraspace
[20:02] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:02] <robint> hi all
[20:02] <tdonohue> in any case, I'm moving along to our main topics for today. First up is Testathon discussions
[20:03] <tdonohue> I wanted to leave some space here to talk about anything Testathon specific in case we need it. But, we could also move on to Hardy's #2 he added to the agenda (which is Testathon related, in that we're trying to fix those test failures)
[20:04] <tdonohue> So, let's talk about the current Unit Testing failure stuff first, and we can loop back around to other issues that we've noticed
[20:04] <helix84> regarding demo.dspace.org, I have 2 TODO items which I didn't get to: 1) enable the mobile theme
[20:05] <tdonohue> I've been following the discussion between robint & KevinVdV about the Unit Testing failure -- it sounds like they've come to the conclusion that the test itself is "flawed" in some way?
[20:05] <helix84> 2) feeding in some more test data https://wiki.duraspace.org/display/DSPACE/Redistributable+Repositories
[20:05] <kompewter> [ Redistributable Repositories - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Redistributable+Repositories
[20:05] <helix84> I'd appreciate any help with that, since the official testathon is coming to an end
[20:05] <robint> Am I correct in saying the only test failure is the Services one ?
[20:06] <robint> Ah, sorry tdonohue, typing too slowly
[20:06] <tdonohue> yes, robint, as far as I know. It's the DSpaceServiceManagerTest failure
[20:06] <robint> Yes
[20:06] <tdonohue> (that's the only failure being reported by Bamboo)
[20:06] <robint> I don't think we can say that the test is flawed
[20:06] <hpottinger> helix84, did you have to turn off any other tests than the one robint just mentioned? when you re-pulled master for deploying on demo?
[20:07] <helix84> hpottinger: i didn't turn off any tests in master. i did it only in my working copy.
[20:07] <robint> But I think we are reasonably confident that any underlying problem highlighted by the test won't manifest itself in real code at the moment
[20:07] <helix84> on demo, i just didn't run them
[20:07] <robint> The truth is we can't explain the failure at the moment
[20:08] <tdonohue> hmm...which is slightly disconcerting, obviously :)
[20:08] <hpottinger> oh, sorry, helix84, I keep thinking in terms of maven releases, which make tests mandatory...
[20:08] <robint> tdonohue: definitely
[20:09] <robint> but the alternative is to go back to an earlier release of Spring which breaks the XMLWorkflow code
[20:09] <tdonohue> so, what is the proposed resolution here? Have we come down to "just disable it for now"? Or is there anyone else who may have ideas? (I know our major Services expert is mdiggory obviously, but he's not here)
[20:09] <hpottinger> from the conversation, I gleaned that there's a difference between how beans are created (programatically vs. from an xml file)
[20:10] <helix84> if we disable it, we should file the problem in jira so that it's not forgotten
[20:10] <robint> hpottinger: correct
[20:10] <robint> helix84: agreed
[20:10] <KevinVdV> I agree
[20:10] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:10] <KevinVdV> I do find it strange however that you CAN retrieve the bean by name but just not by type
[20:11] <hpottinger> so, robint, that would seem to point to something "a little off" in Spring itself... maybe if we change the way the test creates the beans it needs?
[20:11] <mhwood> I'm still puzzled as to how the test ever succeeded. If the thing's a singleton there should be only zero or one of them, yes?
[20:11] <robint> mhwood: actually no, Spring uses the term Singleton differently from our historical use
[20:11] <mhwood> Ah.
[20:12] <robint> Just to confuse
[20:13] <robint> Coincidentally, or not, this release os Spring contains a bug fix to improve the way getBeansByType() works
[20:13] <robint> it *might* be related
[20:13] <KevinVdV> Could you give me a url for that robint?
[20:14] <robint> Yes I'll dig it out
[20:14] * tdonohue was gonna ask the same thing... would be nice to gather all the info that we have figured out / may be related (perhaps in a JIRA ticket?)
[20:15] <hpottinger> if it requires work, it oughta be a ticket, I agree tdonohue
[20:15] <robint> Anyway, given that we haven't seen any 'real' related bugs so far my vote would be to stick with this version of Spring but continue investigating around a Jira ticket
[20:16] <KevinVdV> The code that is tested isn't used in DSpace at the current time (I checked)
[20:17] <tdonohue> That sounds reasonable to me. So, would you be willing to create a JIRA ticket on this robint? & add everything that you've figured out or may be related?
[20:17] <mhwood> In that case I agree: turn the test off for now and study it, but don't hold up the release process.
[20:17] <robint> Will do
[20:18] <tdonohue> +1 mhwood -- let's disable this for now, track it, but not hold things up
[20:18] <KevinVdV> I will fill in any blanks robint
[20:19] <tdonohue> (and if we figure out a resolution before 3.0, great...if not, as long as things are well tested, we should be OK, and hopefully we can figure it out after 3.0)
[20:19] <robint> Sounds good, cheers
[20:19] <hpottinger> +1 mhwood, if the test is for code that isn't actually used, as KevinVdV says... no harm, might as well get on with cutting a new release and all that...
[20:20] <tdonohue> so, once we get this test disabled & tracked in JIRA, do we have someone ready to cut 3.0-rc2 (as we may as well do a new RC, since we've already gotten quite a few bug fixes in)
[20:20] * hpottinger raises his hand, but looks a tad nervous about it.
[20:21] <robint> Well done hpottinger :)
[20:21] <tdonohue> go for it hpottinger. You'll do fine. It's actually good practice as there's no specific timeline on this RC2, so if you need extra time or things go odd, no worries :)
[20:22] <sands> yes, you'll do fine hpottinger. i can lend advice if you let me know when you're cutting it.
[20:22] <helix84> i'd like to ask for a little brainstorming here. I hit an issue with master HEAD on my local machine today - "SolrException: Internal Server Error" on any Solr query, including update-discovery-index. I tried deleting the search core data and I made sure my schema.xml is up-to-date. I also deleted [dspace]/solr let ant update comletely recreate it. so the brainstorming question: what are some possible causes Solr could be throwing HTTP error
[20:22] <helix84> 500?
[20:23] <mhwood> I presume that it logged nothing revealing.
[20:23] <helix84> mhwood: exactly, but let me pastebin it just to make sure i'm not losing sight
[20:24] <tdonohue> helix84 -- I'd also agree that a check of logs may be necessary. Also may want to ensure you have the right port configured for Solr, etc. (though it sounds like it is finding Solr, and something else is going wrong after that)
[20:25] <hpottinger> sands: thanks, I will take you up on that offer, and will rely on your help to ensure there's a proper soundtrack, too. :-) AND on robint to disable that test.
[20:25] <helix84> tdonohue: my solr address is correct
[20:25] <tdonohue> Ok, so, looping back around on our agenda. Any big things to discuss in testing / Testathon? Any things folks have noticed or need help on? (Also, we have a TON of new JIRA bugs we could dig through and assign to volunteers today if we get to it)
[20:26] <robint> Should we extend the Testathon ?
[20:26] <tdonohue> it's a good question... I'm not against it.
[20:26] <mhwood> More like deploy an RC2 instance and declare a new Testathon?
[20:26] <helix84> i'd say yes
[20:26] <hpottinger> robint: I think we should, I would like to ensure rc2 gets a fair shake
[20:26] <helix84> http://pastebin.com/unadJyfA
[20:27] <kompewter> [ Spam Detection For Paste ID: unadJyfA ] - http://pastebin.com/unadJyfA
[20:27] * tdonohue is checking Google Analytics on demo.dspace.org to see what sort of activity we've had
[20:28] <mhwood> helix84: actually I wondered if *Solr* logged anything useful.
[20:28] <helix84> mhwood: ah, yes, let me check again
[20:29] <helix84> mhwood: nope, not a beep
[20:29] <KevinVdV> Ps: if we are going for RC2 could anybody take a quick look @ the following pull requests of mine & accept/comment: https://github.com/DSpace/DSpace/pull/96, https://github.com/DSpace/DSpace/pull/101
[20:29] <kompewter> [ [DS-1325] Every Item page has an HTML <title> of "Version History" by KevinVdV · Pull Request #101 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/101
[20:29] * sands passes hpottinger a copy of "Don't Fear The Reaper"
[20:30] * hpottinger faints.
[20:30] <tdonohue> KevinVdV -- the Pull#101 looked good to me, but it cannot be auto-merged
[20:31] <tdonohue> KevinVdv -- Pull #96 looks good at a glance (haven't tested it, but the fix looks reasonable to me)
[20:31] <helix84> could someone who uses CC licenses in submission workflow in XMLUI please look at https://github.com/DSpace/DSpace/pull/103
[20:31] <kompewter> [ [DS-1336] Creative Commons Locale by helix84 · Pull Request #103 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/103
[20:31] <KevinVdV> No ? I see a green "Merge pull request button"
[20:32] <hpottinger> so do I :-)
[20:32] <KevinVdV> So who wants to push the button ?
[20:32] <tdonohue> oh wait -- that's odd. I thought I saw the gray button on pull #101 (my eyes are messing with me)
[20:32] <helix84> houston: eagle is cleared for landing
[20:33] <tdonohue> I'm feeling "button happy" today...I'll click the button on #96 & #101 ;)
[20:33] <helix84> umm, you're not going to build them? :p
[20:33] * hpottinger cheers for tdonohue.
[20:34] <helix84> wow, this "testing" is easier than I thought
[20:34] <tdonohue> 101 already looked good (I tried it out). 96 looks rather small, and I'm gonna just "trust it". If it fails, I'll roll it back.
[20:34] <KevinVdV> Thanks tdonohue
[20:34] <hpottinger> "trusted developers" and all that, we used to "just commit" all the time.
[20:35] <helix84> i think i', going to push a lot of buttons today. and throw in a prayer.
[20:35] <tdonohue> button pressed on both. We'll wait for Bamboo to complain (currently though it will complain about that one known unit test)
[20:36] <helix84> actually I was going to test #101 today, just spent the rest of my day on the solr issue
[20:36] * mhwood remembers seeing any number of untried patches on the Linux Kernel ML labelled "obviously correct".
[20:37] <tdonohue> Ok, so I've got a topic for you all. Have any of you tried out our IDE instructions for 3.0 + build.properties? News flash: They don't entirely work (our old "dspace.config" property that helped you run a webapp from your IDE is gone)
[20:37] <tdonohue> I emailed dspace-devel about this, but I figured I'd ask to see if I'm just being dumb and overlooking something obvious here?
[20:38] <tdonohue> Essentially, I want to be able to kick off a DSpace WebApp from my IDE so that I can debug it live, etc. I used to do that via the "dspace.config=[path-to-dspace.cfg]" property, but that's now gone
[20:39] <hpottinger> doesn't build.properties give you the same thing that the dspace.config property gave you?
[20:39] <tdonohue> hpottinger -- I cannot get it to work right yet in NetBeans at least. But, maybe I'm doing something wrong.
[20:40] <tdonohue> Essentially, I've tweaked build.properties, kicked off a webapp from NetBeans, and NetBeans errors out (I think the web.xml isn't getting filtered right or something, and the "dspace.config" property used to do that)
[20:41] <tdonohue> But, if no one else is seeing this, maybe it's just me
[20:41] <hpottinger> I've been re-working my IDEA setup to get me into the new Git era... am right at the point of trying to run Tomcat in IDEA, so I can chime in on the mail list if I also run into trouble... but, if there are tricks we need to know about, I'm all ears.
[20:41] <mhwood> Is there a way (from the IDE) to get the servlet container to supply that value, as one can in production?
[20:42] <tdonohue> I just thought I'd ask to see if anyone has tried doing debugging from an IDE with 3.0
[20:42] <robint> Ah! I think I know why...
[20:42] <tdonohue> hpottinger -- I actually don't know the "trick" yet. I'm just reporting that the old "dspace.config" property trick is now broken
[20:42] <tdonohue> robint: I'm all ears ;)
[20:43] <robint> Pre 3.0 - a normal build didn't filter web.xml
[20:43] <robint> but if you specified -Ddspace.config it did
[20:44] <tdonohue> correct, robint.
[20:44] <robint> The original change from Steve Swinburg changed that behaviour so that web.xml was always filtered
[20:45] <robint> But that then meant that you couldn't use -Ddspace.config with Ant to filter at that stage
[20:45] <robint> because web.xml had already been filtered
[20:46] <robint> So I undid the bit that filters web.xml automatically in the Maven build to preserve the old behaviour
[20:46] <robint> have a look at any UI pom and you will see that the filtering is turned off by default
[20:46] <robint> but you can turn it on if your site preference is to filter at build time
[20:47] <robint> Personally I think its all bit messy
[20:47] <robint> Although no more so than it was before
[20:48] * helix84 is hoping that for 4.0, lyncode will save us all with his configuration system rewrite
[20:48] <tdonohue> I guess I still don't fully understand what the "new way" is. It seems like "build.properties" is nice, but I still need to be able to debug webapps from my IDE
[20:49] <tdonohue> But, if there "is no new way yet", then at least I know I have freedom to dig around in Maven and see if I can find a way to enable *both* build.properties and possibly the old "dspace.config" option
[20:51] <tdonohue> In any case, maybe I should take this back to dspace-devel. I don't want to take up all our time here. But, I did want to make everyone aware of this problem, so that hopefully we can determine new "best practices"
[20:51] <mhwood> Any way to set the Context parameter "dspace-config" from your IDE? Just override whatever is in web.xml.
[20:52] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Ping timeout: 245 seconds)
[20:52] <tdonohue> mhwood -- not that I'm aware of. I could set it perhaps in Tomcat directly. But, that's a bit of a "messy" development environment to explain to all the other DSpace Developers out there
[20:52] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:52] <robint> Hi, sorry got kicked out at a bad moment
[20:53] <tdonohue> I was hoping to have something easier...but, again, if anyone has ideas or figures it out for *any* IDE (I suspect they all have this issue), let me know
[20:53] <helix84> i've seen a weak consensus on "extending the testathon" today. does that mean the end date will just move or do we take some time to fix the bugs (a lot of work!) and then announce another testathon round? obviously, the demos erver will continue to run.
[20:54] <mhwood> The RT should decide when an RC is ready to test.
[20:54] <robint> tdonohue: bring it up on dspace-devel and I'll chip in
[20:54] <tdonohue> helix84: either option is open. Some years, we don't do a second testathon (as things were "mostly stable"), but other years we have made decisions to run a second "mini-Testathon" (usually just a week), but usually that's *after* we have time to fix bugs
[20:55] <tdonohue> helix84: as mhwood says -- I delegate the final decision to the RT. But, if they want feedback from all, just ask
[20:55] <tdonohue> robint: it's already brought up on dspace-devel (about 1hr ago), so feel free to chip in with ideas
[20:56] <helix84> tdonohue: I just asked :) I strongly recommend the second option. There are a lot of unfixed bugs. And we should announce another round so that we don't lose testers' attention.
[20:56] <robint> I guess it just depends how quickly we can get through the bugs
[20:57] <hpottinger> Well... there's RCs and then there's bugfix releases...
[20:57] <helix84> from what i've seen here today, it could take as little as 10 minutes :D
[20:57] <robint> :)
[20:57] <tdonohue> Current bug list for 3.0: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.0%22+AND+resolution%3DUnresolved+ORDER+BY+priority+DESC
[20:57] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+fixVersion+%3D+%223.0%22+AND+resolution%3DUnresolved+ORDER+BY+priority+DESC
[20:57] <mhwood> The idea is that if the RCs are well tested then there won't be any bugfix releases. (There always are, but one tries....)
[20:58] <mhwood> OTOH lots of products ship with known minor bugs to be fixed RSN.
[20:59] <tdonohue> as best as we can, I think it'd be good to not ship with "known bugs"...but if they are minor it might not be the worst thing. Just would be good to at least divvy up what is already "known" amongst us
[20:59] <helix84> i don't remember any show-stoppers, but there are a lot of minor ones
[20:59] <hpottinger> so, we could review the list of bugs and identify any that would be blockers for 3.0
[21:00] <mhwood> Classify: (1) must be fixed, (2) can be fixed fast, (3) can wait if necessary.
[21:00] <tdonohue> +1 mhwood... or, we do that via the priority levels in JIRA
[21:01] <helix84> sounds like a job for the RT
[21:01] <mhwood> Next RC waits on 1 & 2. Schedule another RC to take on 3.
[21:01] <robint> Sorry but got to run, cheers
[21:01] <mhwood> Or some 3s will be done post-ship.
[21:01] <tdonohue> It is worth noting I've found one semi-bad bug: DS-1333 (Not recommending that we talk about this now...just wanted to make folks aware)
[21:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1333 ] - [#DS-1333] Versioning an Item causes some metadata values to be lost - DuraSpace JIRA
[21:01] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:03] <tdonohue> I would recommend that the RT go through & categorize bugs & even perhaps attempt to assign some that don't have designees (post about them to dspace-commit or similar to try and get a volunteer?)
[21:05] <tdonohue> (I should also note that the current bug list in JIRA may actually have some tickets that can be immediately closed, as their Pull Request was already committed...I've found a few recently & closed them)
[21:05] <helix84> I will try to do a part. But I'd also like to ask every committer to take a look a the pending bugs (Jira link above) and see what they can fix.
[21:05] * tdonohue notes that RT should not be expected to *fix* the bugs. Just help try and get some volunteers by noting which one need volunteers
[21:06] <KevinVdV> I'm current spending my lunch breaks on fixing as much as I can
[21:06] <tdonohue> The committers just need a poke/prod sometimes :) Usually though folks will step forward & volunteer -- esp. if they accidentally caused the bug
[21:06] <helix84> I'ma fix myself a lunch, too
[21:07] <helix84> :)
[21:07] <KevinVdV> To the release team, if you want me to take a look at a certain issue, just let me know & I will do my best
[21:08] <helix84> thanks, kevin
[21:08] <sands> Thank you KevinVdV.
[21:08] <tdonohue> Ok. we're out of time here. I'll note we didn't get to Hardy's other topic about potentially moving a theme or two into a separate maven project. But, I wonder if that might be better to bring to dspace-devel or similar (it seems too late to do that for 3.0)
[21:08] <sands> Much appreciated.
[21:08] <helix84> did you do versioning? 1333 sounds like a hot candidate?
[21:09] <mhwood> Yes, to dspace-devel.
[21:10] <mhwood> Must go. 'bye all.
[21:10] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:10] <helix84> tdonohue: i missed that about themes
[21:10] <sands> ditto. cheers everyone.
[21:10] * sands (~sandsfish@18.189.25.238) Quit (Quit: sands)
[21:10] * tdonohue does encourage folks to feel free to add topics to the weekly agenda (as hpottinger did this week). Some weeks I may need some prompting on what topics are important to folks. I'm glad for anyone to add to agenda
[21:10] <tdonohue> helix84: It's listed as #3 on today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-10-17
[21:10] <kompewter> [ DevMtg 2012-10-17 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-10-17
[21:11] <hpottinger> oh, yes, I'll bring it up on dspace-devel... I think we really need to consider refactoring themes out of the main repository, to make them easier to trade around
[21:11] <helix84> tdonohue: sounds like a very good suggestion to me
[21:11] <KevinVdV> Takes "DS-1333"
[21:11] <kompewter> [ https://jira.duraspace.org/browse/DS-1333 ] - [#DS-1333] Versioning an Item causes some metadata values to be lost - DuraSpace JIRA
[21:12] <helix84> is PeterDie_ here today?
[21:12] <helix84> thanks kevin!
[21:12] <tdonohue> hpottinger -- yea, I agree it's a very interesting idea. I just don't exactly know how easy/hard it would be (and whether there may be a way to test it out first, before jumping in head first)
[21:12] <helix84> tdonohue: it's easy to test things like this with git. just clone a repo and experiment away.
[21:14] <tdonohue> well, then I'd encourage interested folks to test it out / do a proof of concept & let us know if it seems like it'd be a good way forward for themes. I just don't know enough yet about how git "submodules" work and whether that'd be a better approach for themes
[21:14] <helix84> honest'y, i never _created_ a repo with sumbodules, either
[21:15] <helix84> but i'd leave it up after the release
[21:15] <hpottinger> tdonohue: I'm experimenting with doing a sparse checkout of DSpace/DSpace (just grabbing the Mirage theme folder), and then using a subtree merge into a new bare repository.... but I'm just guessing at this point, it may or may not work.
[21:15] <helix84> tdonohue: there's some admin stuff i just remembered I wanted to talk to you about
[21:16] <tdonohue> what sort of admin stuff?
[21:16] <helix84> something about confluence, but I must remember :)
[21:17] <helix84> I always find bugs and then forget reporting them
[21:18] <tdonohue> well, you can always email me or sysadmin@duraspace.org (our admin list)
[21:18] <helix84> i ought to do it right away when i encounter them. it's always just minor things and then I forget.
[21:18] <hpottinger> bug list, with new bugs on top: https://jira.duraspace.org/secure/IssueNavigator.jspa?sorter/field=created&sorter/order=DESC
[21:18] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?sorter/field=created&sorter/order=DESC
[21:21] <helix84> apropos sysadmin@ - is there just you at the moment or also someone else?
[21:21] <helix84> and do you prefer using sysadmin@ or your personal email?
[21:22] <tdonohue> If it's an admin task (like wiki / jira / etc) that is not DSpace specific, it's best to use sysadmin email. That goes to three people: myself, Bill Branan & Andrew Woods (both work on DuraCloud). If it's something very Dspace specific, you can just email me if you want
[21:23] <hpottinger> and... just the unassigned bugs (12 of them), https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+issuetype+%3D+Bug+AND+resolution+%3D+Unresolved+AND+assignee+is+EMPTY+AND+fixVersion+%3D+10543+ORDER+BY+created+DESC%2C+priority+DESC
[21:23] <kompewter> [ Issue Navigator - DuraSpace JIRA ] - https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+issuetype+%3D+Bug+AND+resolution+%3D+Unresolved+AND+assignee+is+EMPTY+AND+fixVersion+%3D+10543+ORDER+BY+created+DESC%2C+priority+DESC
[21:23] <helix84> thanks, i'll keep that in mind
[21:23] <tdonohue> the obvious bonus for the sysadmin list is that if I'm not around, someone else can take care of it.
[21:24] <tdonohue> hpottinger: nice. It's good the unassigned list is so few
[21:26] <helix84> i'll head out now. have a nice day!
[21:26] * helix84 (a@195.113.97.174) has left #duraspace
[21:26] <KevinVdV> Needs to run
[21:26] * KevinVdV (~KevinVdV@d54C154B1.access.telenet.be) Quit (Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :))
[21:26] <tdonohue> yep..later all. I'm heading into lurking mode too.
[21:30] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[21:55] * tdonohue (~tdonohue@c-67-177-108-221.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[21:57] * hpottinger (~hpottinge@mu-162198.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
){kind=link}
