Timestamps are in GMT/BST.
[6:55] -sendak.freenode.net- *** Looking up your hostname...
[6:55] -sendak.freenode.net- *** Checking Ident
[6:55] -sendak.freenode.net- *** Found your hostname
[6:55] -sendak.freenode.net- *** No Ident response
[6:55] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:55] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:55] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[8:21] * stevew (~stevew@lt91-128.eecs.qmul.ac.uk) has joined #duraspace
[13:12] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[13:52] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[14:00] * stevew (~stevew@lt91-128.eecs.qmul.ac.uk) Quit (Quit: stevew)
[14:02] * stevew (~stevew@lt91-128.eecs.qmul.ac.uk) has joined #duraspace
[15:08] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Remote host closed the connection)
[15:34] * stevew (~stevew@lt91-128.eecs.qmul.ac.uk) Quit (Quit: stevew)
[15:37] * stevew (~stevew@lt91-128.eecs.qmul.ac.uk) has joined #duraspace
[15:38] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[15:54] * stevew (~stevew@lt91-128.eecs.qmul.ac.uk) Quit (Quit: stevew)
[17:13] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[17:15] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[17:43] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[17:46] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[19:34] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) has joined #duraspace
[19:51] <tdonohue> Hi all, reminder that in ~10min we have our weekly DSpace Developer Mtg here. Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-01-11
[19:58] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:00] * richardrodgers (~richardro@18.111.24.146) has joined #duraspace
[20:00] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:00] <tdonohue> Hi all -- looks like we are a smaller group today overall :) In any case, here's the agenda for today (it's mostly an open agenda): https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-01-11
[20:01] <richardrodgers> Welcome back tdonohue
[20:01] <mhwood> "
[20:01] <tdonohue> thanks, good to be back :)
[20:02] <tdonohue> (albeit a little sleep deprived these days)
[20:02] <richardrodgers> don't operate heavy machinery ;)
[20:02] <tdonohue> so, if gibberish starts coming from my keyboard, just assume I've fallen asleep (kidding, mostly)
[20:03] <tdonohue> ok. may as well get started here with the normal JIRA review....from what I could gather from past mtg logs, you all left off at Ds-918.
[20:04] <tdonohue> https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-919+ORDER+BY+key+ASC
[20:04] <tdonohue> we'll start off then at DS-919
[20:04] <tdonohue> https://jira.duraspace.org/browse/DS-919
[20:04] <tdonohue> (no kompewter, I see. oh well, we'll do this manually)
[20:05] <mhwood> Good ideas, I think; just needs an implementation.
[20:05] <richardrodgers> This seems more like a problem statement
[20:05] <tdonohue> +1 to what mhwood said. I like the ideas, we just need someone to "run with this" and bring forward an implementation
[20:06] <aschweer> tdonohue +1 -- it'd be neat to have something better than what we have now
[20:06] <PeterDietz-alt> kompewter is dead, my computer is dead (terrible ethernet stability). My new computer comes next week.
[20:06] <tdonohue> So, if anyone is interested in this area, please feel free to claim Ds-919 (no specific timeframe or deadline expected)
[20:07] <tdonohue> RIP kompewter (you will be missed for the time being), and RIP PeterDietz-alt's old computer :(
[20:08] <PeterDietz-alt> I think we need to use something more updated than iplists.com
[20:09] <tdonohue> (Small digression -- if you felt it useful, PeterDietz-alt, you could ping me about bringing kompewter back to life on DuraSpace servers. It's up to you)
[20:10] <tdonohue> +1 PeterDietz-alt to that idea as well. Would be better to move bot detection away from IP-based (as those IPs are never truly "stable", except for the largest bots like Google)
[20:10] <tdonohue> Ds-919 summary: Needs a volunteer. Support for the idea. Someone should post these notes to JIRA issue as a comment (if no one gets to it, Tim will tackle after meeting)
[20:11] <tdonohue> next up, DS-920: https://jira.duraspace.org/browse/DS-920
[20:12] <PeterDietz-alt> I like expand/collapse. We use it at OSU: See example: https://kb.osu.edu/dspace/community-list
[20:12] <tdonohue> cool idea. patch likely needs a close look though (and testing)
[20:13] * PeterDietz-alt wonders if HTML5 spec has thought about this type of thing
[20:14] <tdonohue> Anyone interested in looking at this patch closer (and investigating the HTML5 question -- I'm also not sure)
[20:15] <PeterDietz-alt> I'll volunteer to get expand/collapse UI in there for collection list.
[20:15] <tdonohue> hmmm...one not-so-good thing about this Ds-920 work. I notice it uses the 'treeview' jQuery plugin which claims to now be unmaintained: http://bassistance.de/jquery-plugins/jquery-plugin-treeview/
[20:15] <tdonohue> PeterDietz-alt -- sounds good. Feel free to claim DS-920 then
[20:16] <tdonohue> moving along, next up: DS-921 https://jira.duraspace.org/browse/DS-921
[20:17] <richardrodgers> maybe ping reporter to see if he still intends to post a new version?
[20:19] * mhwood tries to figure out how they managed to wind up under all those constraints.
[20:19] * mhwood thinks maybe they want to look into Git.
[20:20] <mhwood> It sounds like three issues to me.
[20:20] <tdonohue> not very clear whether this build script uses Maven or not. but, then again, I notice the build script itself wasn't posted for us to review
[20:21] <PeterDietz-alt> I just realized I'm very spoiled now that I have IDEA. Press the green button to rebuild + start tomcat server, press the blue button to rebuild/recompile + hotswap affected classes.
[20:22] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) has joined #duraspace
[20:22] <robint> Hi all
[20:23] <PeterDietz-alt> Edit trunk/dspace/pom.xml to set default.dspace.dir default.dspace.password etc... and have each developer never commit that. They all could use git and have own branches.
[20:23] <KevinVdV> Hi robint
[20:23] <tdonohue> it sounds like all we may be able to do here is ping reporter (as richardrodgers suggests). Until we get the build script, it's hard to tell for sure if there are other recommendations we can give (e.g. using git, or using an IDE to help out with common tasks)
[20:24] <tdonohue> for Ds-921, I'll ping the reporter and ask about this script -- assign tdonohue for now
[20:24] <tdonohue> hi robint
[20:24] <tdonohue> ok, we can stop the JIRA review there for now, and move on to other topics (which are mostly "open discussion" for today)
[20:25] <tdonohue> the only real topic I had was just to congratulate us all on 1.8.1 (robint especially), and ask if anyone has noticed anything necessitating a 1.8.2 yet
[20:25] <tdonohue> (obviously, we don't need to make a decision on a 1.8.2 immediately -- but it's something to keep in mind in coming weeks.)
[20:26] * kompewter (~kompewter@sul272sandbox.lib.ohio-state.edu) has joined #duraspace
[20:26] <PeterDietz-alt> DS-1044
[20:26] <kompewter> [ https://jira.duraspace.org/browse/DS-1044 ] - [#DS-1044] Select Collection step limits length of collection name, leading to difficulty in picking the correct collection. - DuraSpace JIRA
[20:26] <PeterDietz-alt> haa.. fixed it just in time :(
[20:26] <tdonohue> kompewter is back from the dead!
[20:26] * richardrodgers_ (~richardro@18.111.24.146) has joined #duraspace
[20:26] <PeterDietz-alt> I've started to turn the corner to think about 3.x stuff
[20:26] * richardrodgers (~richardro@18.111.24.146) Quit (Read error: Connection reset by peer)
[20:26] * richardrodgers_ is now known as richardrodgers
[20:27] <mhwood> Surprised it doesn't recognize "back from the dead" and respond: "Braaaains!"
[20:27] <tdonohue> haha :)
[20:27] <PeterDietz-alt> I'd like to have some significant improvements underway. But in the mean time.. I'm trying to sneak things in before the ReleaseTeam can notice
[20:27] <PeterDietz-alt> its day time here... It would prefer to be sleeping
[20:28] <tdonohue> PeterDietz-alt -- I agree that I'd rather try to move on to 3.0 things. But, obviously if some major bug pops up, then I'm not against doing a 1.8.2 to stabilize
[20:28] <PeterDietz-alt> thus.. I'm not aware of anything wrong with 1.8.x
[20:29] <mhwood> No complaints about 1.8.1, but...I thought the answer to "are we doing 1.8.2 or 3.0 now" was "yes."
[20:30] <richardrodgers> I also think this should be a 'free period' before we have to worry about releases for a while - we should encourage experimentation, discussions
[20:30] <tdonohue> yea, currently we are still under the assumption that there *may be* a 1.8.2
[20:30] <tdonohue> +1 richardrodgers -- now is definitely the time for major brainstorming / "crazy" ideas / experimentation
[20:31] <PeterDietz-alt> hmm. locally, I'm trying to come up with an alternative to Solr, since we've essentially hit the wall with performance. We're a bit hesitant to buy a VM just for solr, so I've been looking at alternatives (elastic search) that _may_ have better performance than solr. I think KevinVdV has been looking at another commercial search provider.
[20:32] <robint> Do you know where the problem lies with Solr ?
[20:32] <richardrodgers> I've recently started a 'modernizer' track of thinking - taking a small subset of DSpace code and replacing things with newer stuff...
[20:32] <robint> Is it just the quantity of data ?
[20:32] <PeterDietz-alt> several several gigabyte large files that need to be written, and read from disk to accomplish operations
[20:32] <mhwood> So then IIRC there would be some work to do in further decoupling DSpace from ${particularSearchImplementation}?
[20:33] <robint> Thats a pity. Solr promises so much :(
[20:33] <PeterDietz-alt> yep.. xmlui is a bit tied to solr, but thats understandable. I don't know how to abstractly query things.. without doing it the proper way.
[20:33] <tdonohue> RE: Solr, I also wonder whether the fault is Solr itself, or if we do not have a fully "optimized" way of indexing via Solr (i.e. is it how we are using Solr?)
[20:33] <richardrodgers> from 'tired' -> 'wired' (as the magazine used to do)
[20:34] <PeterDietz-alt> basically, I think solr doesn't shard as well as I'd like it to (I'm not a lucene-mailing-list expert, so please don't throw stones at me).
[20:34] <richardrodgers> e.g. log4j -> slf4j/logback
[20:35] <mhwood> I've been using slf4j in new classes, since I noticed we already depend on it.
[20:35] <richardrodgers> java dates -> joda time
[20:36] <richardrodgers> apache commons -> guava
[20:36] <robint> I'm googleing like mad !!
[20:36] <richardrodgers> commons-jdbc -> bonecp
[20:36] <richardrodgers> etc
[20:37] <tdonohue> PeterDietz-alt -- so, are you convinced that Solr is the problem? I know there are some very large scale Solr implementations out there (e.g. HathiTrust): http://wiki.apache.org/solr/SolrPerformanceData
[20:37] <kompewter> [ SolrPerformanceData - Solr Wiki ] - http://wiki.apache.org/solr/SolrPerformanceData
[20:38] <PeterDietz-alt> richardrodgers, I like that too.. I'll be thinking, there's got to be a really easy way for me to output this date object as ISO8601, so i google it, and the answer is use joda... or do SimpleDateFormat("yyyy-mm-...")
[20:38] <mhwood> Um, commons-jdbc is commons-dbcp?
[20:38] <tdonohue> richardrodgers: I like the idea of 'modernizing' DSpace stuff. Are you able to put this work up somewhere so others can "chip in"?
[20:38] <richardrodgers> mhwood: yea, sorry I meant commons-dbcp
[20:39] <richardrodgers> tdonohue: sure - I'll put it up in Github. People can fork it, and apply their own fave libraries...
[20:39] <tdonohue> (i.e. hint hint hint : ever thought of posting your ongoing work up on GitHub so others can fork & help out?)
[20:39] <aschweer> richardrogers: I like your idea too and would be happy to help out a bit
[20:39] <tdonohue> haha...same time, same idea. cool :)
[20:40] <PeterDietz-alt> hey.. this sounds like the perfect opportunity to finish DSpace's migration to GitHub
[20:40] <PeterDietz-alt> all in favor:
[20:40] <tdonohue> +1 to getting this up on Github. I'd chip in (plus this would force us all to start playing with Github)
[20:40] <mhwood> One thing we need to modernize again is the PostgreSQL driver....
[20:40] <PeterDietz-alt> Wait.. are we voting for richardrodgers to put his stuff on github, or... to cut the rope and make all dspace contributions through github
[20:41] <PeterDietz-alt> bc.. this could be as simple as people watching Richards fork of the project on github
[20:41] <richardrodgers> Will do - but for ease of use, I started with a very small subset of DSpace (I'm calling it the 'kernel') - basically a stripped down dspace-api
[20:42] <robint> I'm generally in favour of migrating to Github, but what would be the conseqences for Maven releases ?
[20:42] <tdonohue> PeterDietz -- I'm generally in favor of moving towards github. But, I'm still very much a novice, and I'm not sure of the best "policies" about contributions via github yet (e.g. Fedora established their own best practices for GitHub: https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices)
[20:42] <robint> consequences
[20:43] <PeterDietz-alt> We'll cross the maven bridge when we get there.. And the good news is that the RT will be a series of people figuring it out, instead of just one person.
[20:43] <tdonohue> +1 to what robint said too. But, I'm sure we can do Maven via GitHub, as Fedora already does it.
[20:43] <aschweer> robint: I don't think we'd have maven problems; github seem to be interested in making it easy to use the two together: https://github.com/github/maven-plugins
[20:43] <kompewter> [ github/maven-plugins - GitHub ] - https://github.com/github/maven-plugins
[20:44] <PeterDietz-alt> For using Git, there's SmartGit for windows, perhaps even tortoise git. Mac users have tower. And linux users are hardcore, and will use command line.. or git gui
[20:44] <robint> I am sure we can do it, but our current poms and release procedure do depend on the classic SVN directory structure, so there would be work to be donee
[20:44] <aschweer> I've been using github for my dspace code since we upgraded to 1.7 and I'm really happy with it. Just annoyed I can't have a public and a private fork of the same project in the same user account
[20:44] <aschweer> robint: ah good point
[20:45] <tdonohue> I think my only outstanding concerns with GitHub revolve around what the "preferred workflow" for submissions should be. I noted that Fedora has specifically noted some things that one should NEVER do via git (as it messes others up): https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[20:45] <kompewter> [ Git Guidelines and Best Practices - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[20:45] <tdonohue> but, then again, as Fedora has gone down this path first, we could likely just take the same path they are on
[20:48] <tdonohue> robint -- yea, there will likely be a small pain to clean up all the pom references. But, we could always make sure to run a test release or two after the migration would happen to ensure we have it all working right again (i.e. we wouldn't want to wait until 3.0 release is pending obviously)
[20:49] * richardrodgers_ (~richardro@18.111.24.146) has joined #duraspace
[20:49] <PeterDietz-alt> I think their flow is fine. The only tricky points I can think of is do we want 2 dozen committers with push access to the repo. Or so have 2 dozen committers, each with a fork, the gets pull requested, and then reviewed by the top-most-reviewer... i.e. Linus
[20:49] * richardrodgers (~richardro@18.111.24.146) Quit (Read error: Connection reset by peer)
[20:49] * richardrodgers_ is now known as richardrodgers
[20:50] <tdonohue> PeterDietz-alt : you think Linus would be interested in reviewing our code (kidding)
[20:50] <PeterDietz-alt> I'm sure Linus has written a research paper or two. Its gotta be in someone's repo. Maybe we can check some schools in Finland for it.
[20:50] <aschweer> I'm about to run off into another meeting, but would it work to have push access for all committers *but* an agreement that all contributions are done via pull requests?
[20:51] <tdonohue> yea, I agree though, the big issue here is how we all work together via GitHub. It may initially be a bit of a major change / pain-point early on as we start to figure out what works or what doesn't. But, in the long run, Github seems like it will help, even if there's initial pain
[20:51] <aschweer> sorry, I need to go. bye everyone!
[20:51] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:52] <robint> Now is certainly the time to do it.
[20:52] <tdonohue> +1 to that, robint
[20:52] <mhwood> One other thing that the kernel has is individuals who collect work on different aspects: one person reviews SCSI, another networks, etc. Then they tell Linus when they have a collection they think he should pull.
[20:52] <PeterDietz-alt> hmmm. so module reviewers/admins
[20:54] <tdonohue> so, do we want to do a quick, informal vote here to see where everyone is currently standing on GitHub? (+1 = in favor of move, 0 = not sure / don't care, -1 = I prefer SVN how it is, thank you)
[20:54] <PeterDietz-alt> I'm +1 to going DSpace fully GitHub.
[20:54] <mhwood> 0
[20:54] <tdonohue> I'm +1 (though I know it may be a bit painful early on for some of us)
[20:54] <KevinVdV> 0
[20:54] <robint> 0, but happy to be lead
[20:55] <robint> ... by others thaat is !
[20:55] <KevinVdV> Btw does anybody who has used Github with DSpace have a small readme for the ones who hardly know what Github is (in other words me)
[20:55] <mhwood> DVCS: definitely. Git: probably. GitHub: not quite so sure yet.
[20:55] <tdonohue> KevinVdV, see: https://wiki.duraspace.org/display/DSPACE/Tracking+your+source+code+with+Git
[20:55] <kompewter> [ Tracking your source code with Git - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Tracking+your+source+code+with+Git
[20:56] <richardrodgers> I think vote is premature - we should encourage people to get their GIt feet wet, then decide nearer a major release
[20:56] <tdonohue> Also, some other good Git Resources on the Fedora Wiki (most are actually a bit generic to Git/Github)
[20:56] <tdonohue> Fedora Git Guidelines: https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[20:56] <kompewter> [ Git Guidelines and Best Practices - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Git+Guidelines+and+Best+Practices
[20:56] <KevinVdV> Thanks tdonohue
[20:57] <robint> richardrodgers: Would we want to migrate near a major release ?
[20:57] <tdonohue> Other Fedora Git resources: https://wiki.duraspace.org/display/FCREPO/Working+with+Git
[20:57] <kompewter> [ Working with Git - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Working+with+Git
[20:57] <tdonohue> richardrodgers -- this isn't a formal, binding vote. Merely my trying to see where everyone is at, and who is "on the fence" or "against it"
[20:58] <richardrodgers> robint: not on the edge of the release, but with enough time to plan out release mechanics, etc
[20:58] <mhwood> Why just before rather than, say, just after?
[20:59] <PeterDietz-alt> I should note that I did have a intro-to-git session on 2011-02-09, almost a year ago.
[20:59] <richardrodgers> tdonohue: OK, I see - I'm cool moving to GitHub
[20:59] <tdonohue> I agree with "getting our feet wet" though (and perhaps moving more of our current DSpace projects/work over to GitHub little by little -- for example, if anyone is working on a new "module" or updating an existing one, why not try and move your work to GitHub to get more familiar in that space)
[21:00] <robint> Would it be worth scheduling a date for a vote to encourage (force) us to give it some thought ?
[21:01] <tdonohue> +1 robint. Maybe we say we'll vote sometime in Feb (mid or end)? Gives us a month to ponder things, and also ensures that if we decide to move, we are doing it very *early* in the 3.0 development cycle (so that 3.0 isn't affected)
[21:01] <robint> Sounds like a good timetable
[21:01] <richardrodgers> I've got to run - but I will put up the 'modernizer' stuff in the next few weeks....
[21:02] <tdonohue> thoughts on that? I can send an email to dspace-commit & dspace-devel about this concept and we can set a deadline to vote as end of Feb.
[21:02] * richardrodgers (~richardro@18.111.24.146) Quit (Quit: richardrodgers)
[21:02] <mhwood> Vote in Feb. sounds reasonable.
[21:02] <robint> tdonohue: +1
[21:03] <PeterDietz-alt> A proper heads-up to the lists is a good idea.
[21:04] <PeterDietz-alt> Already the dspace/webmvc module lives fully on github.
[21:04] <tdonohue> Ok, sounds good. I'll take on a task of emailing dspace-commit & dspace-devel about this discussion. I'll encourage everyone to start playing with Github, and warn that a final vote is coming on Weds, Feb 29 (our last DSpace Devel meeting in Feb)
[21:04] <PeterDietz-alt> I talked to Bojan when we were at the Google Mentor summit about moving the REST API to github, and we has on the fence. He doesn't know git.
[21:04] <tdonohue> it's a leap day vote on taking a leap to Github! :)
[21:05] <PeterDietz-alt> .g leap day
[21:05] <kompewter> PeterDietz-alt: http://en.wikipedia.org/wiki/February_29
[21:06] <tdonohue> To this end, I'm also planning to talk to RichardRodgers about moving our 'dspace-replicate' (Replication Task Suite) work to GitHub as well.
[21:06] <tdonohue> Ok. we're over time here I see. So, folks are free to head off if you need to. This is the last topic for today, so the meeting is adjourned. I'll stick around though if others have things to discuss
[21:07] <PeterDietz-alt> if anyone has questions or doubts about git / github, feel free to pose them to me. I'm pretty knowledgeable/biased on the subject.
[21:07] <PeterDietz-alt> ...or push them to the list, once tim emails the list.
[21:07] <robint> I'm curious to know how tags, branches, trunk etc work in Git land
[21:08] <tdonohue> Thanks, PeterDietz-alt. I may take you up on some of that myself in coming days/weeks (as I'm still learning & getting my feet wet) :)
[21:08] <PeterDietz-alt> tag is just a named commit. Nothing gets copied into a directory called tags. Just there is a pointer with a name to a commit at a specific point in time.
[21:09] <PeterDietz-alt> but our existing tags have migrated to github, and on release day, the RC will just pick the pencils down commit, and tag it.
[21:09] <tdonohue> robint: I'd encourage reading some of the Git resources that Fedora folks have compiled from around the web: https://wiki.duraspace.org/display/FCREPO/Git+Resources (that's how I've slowly been learning about the differences between Git & SVN)
[21:09] <kompewter> [ Git Resources - Fedora Repository Development - DuraSpace Wiki ] - https://wiki.duraspace.org/display/FCREPO/Git+Resources
[21:10] <robint> Ok thanks.
[21:10] <PeterDietz-alt> To think about branches., I'll have to think backwards. i.e. all development gets levied against master (read: trunk)
[21:11] <PeterDietz-alt> then when its time to sunset one line of development and then to shift to another line. i.e. we've just released 1.8.0, then we create a branch, which gets commits pushed to it as needed for the bug fixes. But all other activity would stick to master.
[21:14] <robint> When doing the Maven release Maven nicely creates an SVN tag and branch for you. I wonder if it does equivelant actions for Git. You would hope so.
[21:14] <tdonohue> robint: Also, just found this resource -- an intro to Git for those who know SVN: http://git.or.cz/course/svn.html
[21:14] <kompewter> [ Git - SVN Crash Course ] - http://git.or.cz/course/svn.html
[21:15] <tdonohue> robint -- yea, I would hope so. I think it does, but I'd have to check with Fedora on how they are generating their branches & tags in GitHub: https://github.com/fcrepo/fcrepo
[21:15] <kompewter> [ fcrepo/fcrepo - GitHub ] - https://github.com/fcrepo/fcrepo
[21:15] <robint> Perfect ! I have reached the age when evrything new has to be explained to me in terms of something I already know :)
[21:15] <tdonohue> haha :) yea
[21:16] <robint> I'm a +1.
[21:16] <PeterDietz-alt> Even if maven didn't create those things for you, (i.e. it just touched your master, and altered the poms.)
[21:17] <PeterDietz-alt> In git its an easy, and sometimes common task to jump back in time, and branch off of a previous commit. So, the RC would after the fact, create the tag and the branch. Just a few minutes of work.
[21:18] <KevinVdV> Need to run, thanks for all the git information, will hopefully get my feet wet in the weekend (so I can switch from 0 to +1 (hopefully))
[21:18] * KevinVdV (~KevinVdV@d54C14B50.access.telenet.be) Quit (Quit: KevinVdV)
[21:18] <PeterDietz-alt> And instead of being scary operations (tagging, branching), in Git, its not scary at all. Especially since it initially just alters your local copy, and not replicating your mistake world wide. So if you mis-tag you delete the tag, fix it, then push to the world.
[21:19] <mhwood> Nah, those aren't scary. Merging a vendor drop...that's scary.
[21:20] <tdonohue> Sonatype also has a reference to performing Maven Releases from GitHub: http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/ (At a glance looks very similar to our current Sonatype release processes)
[21:20] <kompewter> [ Sonatype Blog ยป Maven Tips and Tricks: Using GitHub ] - http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/
[21:20] <robint> I've git to run (groan). Cheers all.
[21:20] * robint (52292725@gateway/web/freenode/ip.82.41.39.37) Quit (Quit: Page closed)
[21:21] <PeterDietz-alt> if your vendor had a git repo as well, you could do your vendor as a remote submodule. So that their drop is just "check out version 4.0 of xProject", as opposed to extracting a tar ball in a directory.
[21:23] <mhwood> Well, that's exactly why I want a DVCS, even though I have to learn to work in it. Right now, every time DSpace releases, I merge it into our local SVN so I can use SVN's comparison tools between stock DSpace and our local instances. I do think Git will make this easier once I'm comfortable with it.
[21:27] <PeterDietz-alt> I'll admit that since I jumped the gun on git, i.e. making OSU's DSpace repository use git before duraspace/dspace used git. I can't easily merge the upstream changes into our local system. I will set the record straight when we upgrade to 1.8 (we're at 1.7 now).
[21:29] <PeterDietz-alt> I'm gonna head back over to my main computer (with flaky networking). I can't do my regular work from this lab machine
[21:30] <mhwood> Yes, I need to tend to some other stuff too.
[21:30] <PeterDietz-alt> so.. later all. Maybe a good exercise for teaching people Git, would be to put an html site into github. i.e. the content of the splash page of demo.dspace.org...
[22:11] * mhwood (mwood@mhw.ulib.iupui.edu) Quit (Remote host closed the connection)
[23:03] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[23:03] * PeterDietz-alt (~dspace@sul272sandbox.lib.ohio-state.edu) Quit (Quit: Leaving)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.