Timestamps are in GMT/BST.
[1:39] * ksclarke (~kevin@adsl-39-65-246.clt.bellsouth.net) Quit (Quit: Leaving.)
[3:31] * stuartlewis (~stuartlew@s-lewis.itss.auckland.ac.nz) Quit (Quit: stuartlewis)
[6:42] -card.freenode.net- *** Looking up your hostname...
[6:42] -card.freenode.net- *** Checking Ident
[6:42] -card.freenode.net- *** Found your hostname
[6:42] -card.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
[7:03] * Tonny_DK (~thl@130.226.36.117) has joined #duraspace
[10:32] * grahamtriggs (~grahamtri@62.189.56.2) has joined #duraspace
[12:26] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) has joined #duraspace
[14:14] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[14:37] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[14:39] * ksclarke (~kevin@adsl-39-65-246.clt.bellsouth.net) has joined #duraspace
[14:45] * granitize (~Adium@137.149.66.159) has joined #duraspace
[14:47] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) Quit (Quit: Heading out...talk to you later.)
[14:48] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has joined #duraspace
[15:04] * vzafrin (~veek@209-6-54-68.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) has joined #duraspace
[15:04] <vzafrin> Good morning, folks.
[15:14] <vzafrin> We might have a programmer intern this spring and summer at BU, an LIS student. We're still in the beginning stages of repository management with DSpace, so I can already think of some projects for him -- but am wondering if there's something he could do that would be useful to us *and* the DSpace development cycle.
[15:14] <vzafrin> Is this afternoon's meeting the place to ask that question? Or one of the mailing lists? Or here-now?
[15:18] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (Ping timeout: 264 seconds)
[15:21] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[15:38] * scottatm (~scottatm@adhcp136.evans.tamu.edu) Quit (Read error: Connection reset by peer)
[15:46] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[16:03] * scottatm (~scottatm@adhcp136.evans.tamu.edu) has joined #duraspace
[16:59] * grahamtriggs (~grahamtri@62.189.56.2) has left #duraspace
[19:09] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) has joined #duraspace
[19:14] -card.freenode.net- *** Looking up your hostname...
[19:14] -card.freenode.net- *** Checking Ident
[19:14] -card.freenode.net- *** Found your hostname
[19:14] -card.freenode.net- *** No Ident response
[19:14] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[19:14] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[19:14] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[19:49] * PeterDietz (~PeterDiet@128.146.175.194) has joined #duraspace
[19:54] * eddies1 (~eddies@78.114.137.159) has joined #duraspace
[19:57] <tdonohue> All -- DSpace Developer Mtg starting here in a few minutes. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-02
[19:58] * eddies (~eddies@unaffiliated/eddies) Quit (Ping timeout: 264 seconds)
[19:59] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[20:00] * alxp (~alxp@PC044.ROBLIB.UPEI.CA) Quit (Quit: alxp)
[20:00] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) has joined #duraspace
[20:01] <tdonohue> Hi all, DSpace Developers meeting is starting now (I hope those in the Central/NW USA are not completed snowed under). Agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-02
[20:01] <tdonohue> We'll kick off with a JIRA review for a bit. Here's the list of issues to be reviewed: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-675+ORDER+BY+key+ASC
[20:02] <tdonohue> Starting our review with: "XMLUI doesn't start if the error level in the log4j.properties is set to DEBUG" https://jira.duraspace.org/browse/DS-675
[20:03] <grahamtriggs> that's one of the most amusing bugs I've seen - "Let's debug this... oh, wait"
[20:03] <richardrodgers> seems desirable to have DEBUG level logging: +1 to fix
[20:03] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[20:03] <tdonohue> yea, it is a bit of a shame (and amusing at same time)
[20:03] <tdonohue> I agree, +1 to fixing DS-675, preferably soon
[20:04] <tdonohue> Any volunteers to work on DS-675?
[20:04] * mdiggory (~mdiggory@rrcs-74-87-47-100.west.biz.rr.com) has joined #duraspace
[20:04] <PeterDietz> I do see someone's name in the comments on the issue, hmm...
[20:05] <tdonohue> mdiggory & stuartlewis -- we're looking at https://jira.duraspace.org/browse/DS-675 and also looking for a volunteer to fix it
[20:05] * robint_ (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[20:05] <stuartlewis> I had a brief look at that once, but like Kim, couln't work out what was happening.
[20:05] <tdonohue> yea, I noticed kshepherd verified DS-675 for us, but not sure if he knows a fix
[20:06] <tdonohue> anyone else want to try at DS-675, or have some expertise in the area of cocoon/log4j debug settings?
[20:06] <mdiggory> did anyone test not pushing all the cocoon logging into cocoon.log and see if it still caused problems?
[20:07] <tdonohue> mdiggory -- no idea, could be worth a try
[20:09] <tdonohue> Ok, in essence of time, we'll leave DS-675 unassigned for now. I will schedule it for 1.7.1, so that we are reminded of it in coming weeks/months. Anyone who finds some free time, please see if you can help with DS-675
[20:09] <mdiggory> something else changed awhile back that kinda made logging a pain as well..
[20:09] * robint_ (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Client Quit)
[20:09] <mdiggory> we no longer have a plain old dspace.log, its always prepended with a date
[20:10] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) has joined #duraspace
[20:10] <mdiggory> used tprepended = appended
[20:10] <mdiggory> doesn't this make it difficult for folks to monitor logging, always having to chase the date?
[20:10] <tdonohue> mdiggory -- i noticed that, but I think that was a feature of 1.6? (if i'm remembering right), so that you could make sure to keep *all* your logs -- otherwise, eventually they'd overwrite each other eventually
[20:11] * mdiggory ponder how error logging got tangle with access loging....
[20:11] <tdonohue> (i.e. when they were, dspace.log.1, dspace.log.2, etc, eventually they'd loop around on each other -- there was some maximum number, if i recall correctly)
[20:11] <tdonohue> mdiggory that is a good question :)
[20:12] * mhwood (~mhwood@adsl-99-172-138-251.dsl.ipltin.sbcglobal.net) has joined #duraspace
[20:12] <tdonohue> ok, moving on for now, so we can get a few more issues in here...
[20:12] <tdonohue> Use groupId and artifactId from the dspace-api POM in Util.java : https://jira.duraspace.org/browse/DS-676
[20:12] <tdonohue> grahamtriggs is assigned for DS-676, graham, anything you want reviewed or comments on?
[20:12] <mdiggory> next
[20:13] <grahamtriggs> what I've proposed works. question is whether people want it
[20:13] <mdiggory> yes... that is somewhat a pain, especially when this first came in as a feature, those of us working IDE actually did not have a jar to look this up in
[20:14] <tdonohue> wondering, is there an advantage to only filtering the Util.java file? or is it just as easy (or easier) to filter all source code?
[20:15] <mdiggory> grahamtriggs: think its logical, but also think maybe "generated sources" could be used to write a filtered properties file rather than altering java
[20:15] <mdiggory> sorry generate-resources
[20:15] <mhwood> Generated resource sounds the best yet.
[20:17] <tdonohue> yea, I like mdiggory's idea of a filtered property file. I worry about filtering all our Java code (though it also is likely safe)
[20:17] <grahamtriggs> so pom.properties will always go into /META-INF/maven/org.dspace/dspace-api/ - regardless of what the pom actually says is the group / artifact id?
[20:17] <mdiggory> are you changing the group id of dspace-api?
[20:18] <grahamtriggs> note that the problem isn't what's in the property file, but where it is being placed in the JAR hierarchy
[20:18] <grahamtriggs> mdiggory: yes - so I don't get any accidental resolutions to the published dspace-api in maven central, when I need to use my customized version
[20:19] * mdiggory X get past me Satan!
[20:19] <mhwood> Put this kind of thing into "[somedir]dspace-statics.properties" and you don't care where it is, as long as it's on the CLASSPATH.
[20:19] <mdiggory> sorry... knee jerk reaction
[20:20] * keithgilbertson (~keithgilb@lawn-128-61-20-104.lawn.gatech.edu) has joined #duraspace
[20:20] <mhwood> Ha, that's one I need to remember.
[20:20] <mdiggory> ok, I guess if your so bold to do that...
[20:20] <tdonohue> +1 to mhwood -- I was thinking the same thing. Why not have a separate filtered *.properties file for this info (if possible), rather than depending on pom.properties at all
[20:20] <mdiggory> I asume you change the gid/artifactid coordinates, it will change the location of the file
[20:21] <mdiggory> I think... if we say we are going to create a file dspace-version.properties...
[20:21] <mdiggory> that would be in the resources/classpath, then we can fix the location
[20:21] <grahamtriggs> mdiggory: yes, that's what happens - change the groupId, and the pom.properties gets inserted into /META-INF/maven/YOURGROUPPACKAGE/dspace-api
[20:22] <grahamtriggs> mdiggory: and then filter that file to take the version that's in the pom....
[20:22] <tdonohue> +1 to a dspace-version.properties file (which is filtered). It seems odd to me to do all these workarounds just to access the pom.properties
[20:22] * mdiggory weeps sadly that we will never stop overriding classes...
[20:23] <mdiggory> well, TBH, it could contain much more detail than the pom
[20:24] <tdonohue> should we stop there? any other comments on DS-676?
[20:24] <mhwood> I never liked depending on a file magically provided by Maven that I just happened to notice, but I'm still finding my way around Maven and grasped at it as a possible way for DSpace to *know who it is*, for pity's sake.
[20:24] * grahamtriggs doesn't care about overriding classes. This is, to an extent, what open source development is all about. Remember that local changes may be a future contribution, and clearly we can't evolve the platform if we never change the core classes.
[20:24] <mdiggory> More like a JAR Manifest, but I prefer a properties file because there may not yet be a jar when this is being tested
[20:25] <tdonohue> Ok. sounds like we have some agreement that a separate properties file should be used for DS-676. We'll stop there for today and move on to next topics
[20:26] <mdiggory> onward
[20:26] <tdonohue> Ok, this is out of the DCAT group (vhollister has also joined us today). A proposal for how Committers can potentially share burden of Feature Request reviews/responses with DCAT. https://wiki.duraspace.org/display/DSPACE/NewFeatureReviewWorkflow
[20:27] <vhollister> hi all!
[20:27] <tdonohue> This is up for comment/discussion. You are welcome to comment here, now, or can send comments via email to Val or I.
[20:28] * stuartlewis is going to stick my head out here. Do we have an issue with that at the moment? Or is our biggest issue, as it has always been, development effort / code review & testing / committing effort.
[20:28] <mdiggory> sounds like the old-style bugzilla voting process
[20:29] <mdiggory> voting is good, grass roots efforts to increase ranking in JIRA by voting are good too
[20:29] * keithgilbertson (~keithgilb@lawn-128-61-20-104.lawn.gatech.edu) has left #duraspace
[20:29] <tdonohue> stuartlewis -- at the moment, we do have some issues. Several "Feature Requests" are basically "ideal" in JIRA. The goal is to see if DCAT can help review those ideal issues, to see if they are still relevant
[20:29] <tdonohue> and potentially, see if DCAT can help find resources (committer or non-committer) to start to develop feature requests that it deems as "important"
[20:30] <stuartlewis> That second part will be the most useful.
[20:30] <grahamtriggs> I sat in on the DCAT call yesterday - intending it to be from an OR/user perspective rather than committer - and yes, we do need clearer lines of communication between committer and DCAT groups
[20:30] <tdonohue> So, essentially, this is a proposed way to avoid issues becoming idle :)
[20:30] <tdonohue> (whoops, I said "ideal" before when I meant to type idle -- it's not ideal to have issues be idle :)
[20:31] * vhollister2 (48c88f7e@gateway/web/freenode/ip.72.200.143.126) has joined #duraspace
[20:31] <mhwood> That sounds quite useful.
[20:32] <richardrodgers> One possible method for DCAT to explore are resource pooling models
[20:32] <tdonohue> glad to see a few of us feel this could be useful (I agree). It's really a matter of trying to figure out how best to communicate between DCAT and committers. Currently, we are proposing JIRA as a main communication mechanism, but we are open to ideas (obviously, committers can sit in on DCAT meetings, and DCAT folks can sit in here as well)
[20:32] <vhollister2> we are refining the process -- and need to make sure we can get status updates and realistic assessments from the JIRA assignee about the likelyhood of the work getting done
[20:33] <vhollister2> the idea is if the assignee can't get the work done for the next release, DCAT tries to generate some add'l help
[20:33] <tdonohue> richardrodgers -- could you expand on what you mean by "resource pooling models"? Do you mean finding ways to pool together developer time, and "deal it out" or similar?
[20:33] <robint> I prefer Option A, let the current assignee comment in the first instance.
[20:33] <stuartlewis> (I agree in principle - don't want anyone to think I'm putting the idea down. Just wanted to ask the question!)
[20:33] <mhwood> I've been concerned for a while that we don't ever get time to loop back through issues already discussed once.
[20:33] <richardrodgers> by which I mean: there may be a large number of adopters with common needs. Each individually lacks developer resources, but..
[20:34] <richardrodgers> maybe they could get together and fund development (say, a consulting company, or temp hire)
[20:34] <tdonohue> aha. I understand now. So, pooling money or developer time, to get something done for the benefit of all
[20:34] <mhwood> Hmmm, adding manpower to a project already under way. See _The Mythical Man-Month_. Must be careful *how* we add resources.
[20:35] <stuartlewis> The worry with that, is that if a small consortium funds something, and the committers refuse to commit it for some reason... Need a link in to the committers / Duraspace.
[20:35] * eddies1 (~eddies@78.114.137.159) Quit (Ping timeout: 240 seconds)
[20:36] <grahamtriggs> suggestion by richardrodgers is possible - although first step is still to identify what is important and to agree feasibility (there may be potential resources anyway if people realise it's important, or we may have good reasons why something can't be done just yet)
[20:36] <mdiggory> This is something that has been discussed in the RSP group, we are interested in how we can come together and partner on projects that may be unpopular from a funding standpoint, but be very necessary from a development standpoint.
[20:36] <vhollister2> robint: just need to make sure that everyone is responsive for option A to work, otherwise DCAT will get frustrated
[20:36] <richardrodgers> good point stuartlewis , but I'm looking to a world of asynch releases & add-ons
[20:36] <stuartlewis> mdiggory: RSP?
[20:36] <mdiggory> Registered Service Provider
[20:38] * ianthe (~ianthe@cowu.be) Quit (Ping timeout: 260 seconds)
[20:38] * ianthe (~ianthe@cowu.be) has joined #duraspace
[20:39] <tdonohue> Ok. I think these are all things to consider. I'm sure there will be evolution of this who process. The end goal here though is to bridge communication between DCAT and Committers, which can allow DCAT to help find/locate resources (obviously, this means, we need to be able to provide status updates, so that DCAT knows whether we actually need more resources, or not)
[20:41] <mdiggory> many of us in the RSP group represent direct client interests, and may be able to leverage these clients to organize larger tasks that span them. But as RSP, we work internally to attain such goals. Having a group that could present the "needs" such that they were "identified" by the Duraspace organization as "of great importance" could be of benefit in securing resources for such activities.
[20:41] <tdonohue> So, to get this sort of communication started, I'd like to suggest we may wish to revisit any issues which are commented on by DCAT in our weekly meetings (at least just to get comfortable with this idea, eventually we could end up more with Option A mentioned in the proposal)
[20:41] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[20:42] <tdonohue> ack. Realizing the time here. Any other thoughts/comments to add before moving on for now? obviously, we can continue to revisit this DCAT/Committer collaboration
[20:44] <tdonohue> Ok. Moving on for now (send more comments/ideas/brainstorms if you have them to Val or I)
[20:44] <mdiggory> So, seems next is 1.8.0 release discussion
[20:44] <tdonohue> 1.8.0 Release Numbering Discussion. What are our thoughts (I know we only have 15 mins left here)? Do we want to call this "1.8", or something else?
[20:45] <stuartlewis> What are the other options?
[20:45] <tdonohue> (essentially, I'd like to announce our 1.8 release date and coordinator, but it might be nice to first decide if we have qualms with calling this "1.8" over the other suggestions)
[20:45] <mdiggory> I'm open to the idea, it lessens the depth of numbering sub modules.
[20:45] <tdonohue> see agenda for other suggestions of numbering: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-02-02
[20:46] <mhwood> If it's not 1.8 then it's either 2.0 or stuff that should be floded back into 1_7_x.
[20:46] <mdiggory> for instance, to be able to do dspace 8.1, 8.2 and minor releases and dspace-api-lang as 8.1.1
[20:46] <mdiggory> rather than 1.8.0 and 1.8.0.1
[20:46] <grahamtriggs> I've always favoured Year.Month for timed releases - with a view to a regular, dependable release cycle. But otherwise, meh.
[20:47] <kshepherd> i think we should call it "Frank"
[20:47] <tdonohue> other suggestions were to change numbering completely: 1.8 becomes "8", by dropping the "1." (mdiggory idea) -- or moving to Ubuntu style numbering, Year.Month (11.10) grahamtriggs idea
[20:47] <kshepherd> Frank's a nice name
[20:47] <mdiggory> 12.12.12 ?
[20:47] <PeterDietz> Frank would work for 1.6, but 1.7 = G, 1.8 = I
[20:47] <grahamtriggs> kshepherd: but what do we call the next release?
[20:48] <mhwood> Easier to remember than Linux 2.6.36 "Flesh-eating Bats with Fangs".
[20:48] <tdonohue> haha :)
[20:48] <kshepherd> seriously though ;) i prefer sticking with 1.x, and if we find ourselves in a corner after 1.9, remember it can go to 1.10 afterwards, instead of 2..0
[20:48] <tdonohue> that's one preference for 1.x -- others?
[20:49] <mdiggory> For asynchronous release, what I really need is means to differentiate between modules release numbers and the full release, and to assure theres little to no confusion
[20:49] <mhwood> If we drop the first digit, what happens when we do make an actual incompatible architectural change?
[20:49] <grahamtriggs> It's interesting... nobody remembers the Ubuntu codenames, everyone falls into the 11.10, 12.04 familiarity. But in Apple's garden, Snow Leopards, Leopards, Tigers, Jaguars roam free...
[20:49] <richardrodgers> I guess I have a slight preference for either mdiggory (8.x) or grahamtriggs - it gets over the brinksmanship of 1..... (waiting for the mythical 2.0)
[20:49] <tdonohue> (I'll admit, I have no real qualms with sticking with 1.x releases -- I've just noticed this comes up as a ongoing question/discussion, so I wanted to give us some time to make a decision for the next release)
[20:50] <mdiggory> so for instance, I need something like DSpace x.x but have modules (dspace-api) with versions like x.x.x
[20:50] <mdiggory> gads... Colloquy
[20:51] <mdiggory> *.*
[20:51] <mdiggory> vs *.*.*
[20:51] <mdiggory> I draw these number strategies from both Maven / MAven Plugins and Cocoon / Cocoon Modules
[20:52] <mdiggory> Which use the same approach
[20:52] <tdonohue> mhwood, I think that is a good question, and something worth thinking about.
[20:52] <mdiggory> So I'm in favor of getting the version number for DSpace shortened
[20:53] <mhwood> Well, if we really do embrace modularity and asynchronous release, then "DSpace" becomes a bag containing selected versions of the modules that everyone needs. That's *all* it is: a declaration that version X of module x and version Y of module y...work well enough together to package them together.
[20:54] <mdiggory> DSpace X.X = module-a-x.x.x + module-b.y.y.y
[20:54] <tdonohue> so far, mdiggory, grahamtriggs, kshepherd and richardrodgers have expressed their opinions, and we have 3 different ideas with no real majority approval. Anyone else have thoughts to share, or just not care one way or the other?
[20:55] <PeterDietz> Even though I do like Ubuntu numbering, but I'm happy to think of 1.8 as DSpace 8
[20:55] <stuartlewis> My preference would be to keep with 1.x, until a time arises when we need to change it, in order to allow a new process.
[20:55] <stuartlewis> Then when we change it, we have a good PR story to go with the change.
[20:56] <kshepherd> to qualify my opinion, i'm not so much in favour of 1.x as i didn't realise it was a big problem, so my default position is "do nothing"
[20:56] <mdiggory> Release logo http://www.redkid.net/generator/8ball/yoursign.jpg
[20:56] <kshepherd> but then, i haven't been around as long as some.. i can see that the "never getting to 2.x" problem might be getting annoying
[20:57] <mhwood> But we haven't gotten there. There is a lot of stuff still to be taken up from what I think of as DSpace II -- the architecturally-incompatible stuff.
[20:57] <tdonohue> I wouldn't consider it a "big problem", but just more of a "concern" of some -- the main concerns I've heard are: (1) the "never getting to 2.x" issue, and (2) that to some people "1.x" still doesn't sound like a "mature system"
[20:58] <tdonohue> (these are just summaries of what I've heard -- not saying that I think needs to be changed)
[20:58] <mhwood> "Stable architecture since the mid '90s" sounds mature to me.
[20:58] <tdonohue> I agree, mhwood :)
[20:59] <richardrodgers> I agree also - what system were you referring to?
[20:59] <PeterDietz> dspace was born in 2K2
[21:00] <tdonohue> Ok -- since it sounds like we really don't have full agreement here, we may be forced down the "do nothing" route, until we can come to a majority decision
[21:00] <tdonohue> yea, it was born in 2002 :)
[21:00] <robint> so is that +1.0.0 for doing nothing, or +1.0 ?
[21:00] <stuartlewis> Should we ask what the DCAT think (from the public perception point of view)?
[21:00] <stuartlewis> s/the/they
[21:00] <robint> ...sorry
[21:00] * mdiggory :\
[21:01] <tdonohue> we can ask DCAT..that is an option
[21:01] <kshepherd> robint: ;)
[21:02] <mhwood> We need to understand the perception, but the version is communication from the developers to the broader community, so the developers *define* its meaning.
[21:02] <vhollister> i mentioned this in the mtg yesterday, no real response to the idea -- but i also wasn't really asking
[21:02] <PeterDietz> in terms of serious benefits, number scheme difference between base-dspace *.*, and async modules *.*.* would be an actual benefit.. So that would be a reason to do it other than marketing
[21:02] * mdiggory Ohm... Focus and Try Again
[21:03] <tdonohue> mhwood is correct. I think in the end, it really is *our* decision. We don't seem to have a majority in favor of any option right now, but that could change, if mdiggory and grahamtriggs start shopping their ideas around :)
[21:03] <mdiggory> PeterDietz: sees something there
[21:03] <mhwood> Really? My first question would be "*.*.what?"
[21:03] <grahamtriggs> vhollister: the issue there may be that they have no advocacy of the options, so can't see why one thing or another may be beneficial
[21:05] <PeterDietz> base-dspace: 8.alpha1, 8.alpha2, 8.beta1, 8.rc1, 8.0, 8.1 ----- dspace-discover: 1.0.0, 1.1.0, 1.2.0 ...(?)
[21:05] <mhwood> No testing for 8.1?
[21:06] <mdiggory> Anyhow... I will continue to use a strategy in the async work such that the modules will use *.*.*, the final versioning of the product itself is actually marketing.
[21:06] <grahamtriggs> mhwood: by the time we've worked out what version number it should have, there won't be any time to test it
[21:07] <mhwood> mdiggory: I was hoping to avoid "DSpace Vista" and suchlike.
[21:08] <mdiggory> By the way... https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release
[21:08] * vzafrin (~veek@209-6-54-68.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com) Quit (Quit: Leaving)
[21:08] <mdiggory> mhwood: true
[21:08] <tdonohue> yea, thanks for that work mdiggory -- i saw the JIRA issue get posted :)
[21:08] * kshepherd is willing to be convinced.. i wonder whether this is best debated (and examples given) on the mailing list?
[21:09] <tdonohue> Ok. We're now running over a bit here. We can revisit this going forward.
[21:09] <mdiggory> Working the patch for this atm... heading towards something that can be applied to a local checkout and tested...
[21:09] <tdonohue> sure, if we want to take this to 'dspace-devel', be my guest. I guess the default right now is that it is called "1.8", but we can always rename it if there are real benefits and a majority in favor
[21:09] <mdiggory> TBH, retaining 1.8.x for the dspace-api etc, while allowing the release number to change is an excellent slight of hand
[21:10] * vhollister2 (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Quit: Page closed)
[21:10] <richardrodgers> yea tdonohue I don't think it needs to be nailed down immediately
[21:10] * vhollister (48c88f7e@gateway/web/freenode/ip.72.200.143.126) Quit (Quit: Page closed)
[21:11] <tdonohue> (i'm still not sure I understand why the slight of hand is so immediately important, though, to be honest. But, I'm also willing to be convinced)
[21:11] <mdiggory> and in that case, to avoid any confusion.... using the 11.10 release number, really separates the two...
[21:11] <tdonohue> richardrodgers, I agree. Just wanted to see if we already had a majority in favor of changing. Since we don't have that yet, we'll call it "1.8" unless something changes
[21:12] <tdonohue> Ok. we're over time here. A quick announcement: Next Week (Feb 9), Peter Dietz will lead a Special Topic Mtg on 'git'
[21:12] <mdiggory> "slight of hand" meaning, the versions of the modules did not actually change scheme, just the release "name"
[21:13] <tdonohue> I will *try* to attend, next week. But, I'll be at code4lib, so it all depends on stable wireless access
[21:13] * mdiggory is 'git'in out of here
[21:13] * robint (5229fe8f@gateway/web/freenode/ip.82.41.254.143) Quit (Quit: Page closed)
[21:13] <tdonohue> So, with that, I'll close up the meeting. But, as always, feel free to hang around a bit.
[21:14] <richardrodgers> bye all
[21:14] * richardrodgers (~richardro@pool-96-237-109-32.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[21:16] <tdonohue> mdiggory & grahamtriggs -- you are both welcome to bring your version numbering suggestions to either dspace-devel or dspace-commit. so, really, feel free to do so. We just need to find a majority
[21:16] <mdiggory> tdonohue: enjoy code4lib, say hello to ksclarke and ryan scherle if you see them
[21:16] <tdonohue> will do!
[21:17] <grahamtriggs> tdonohue: I was wondering whether it would be a good idea for people to pen some advocacy statements and have you co-ordinate, sending them out as one succinct message (or more likely, pointing to a consolidated wiki page of advocacy)
[21:18] <tdonohue> grahamtriggs -- that'd be fine by me as well. Maybe create a wiki page under https://wiki.duraspace.org/display/DSPACE/Proposals ? And both you and mdiggory can write up more detailed thoughts/reasoning on that page. Then I'd be glad to send out to lists
[21:47] <mhwood> Gotta go. Thanks, all!
[21:47] * mhwood (~mhwood@adsl-99-172-138-251.dsl.ipltin.sbcglobal.net) has left #duraspace
[21:47] <snail> who is it who runs http://irclogs.duraspace.org/ ? any chance of getting a link to https://wiki.duraspace.org/display/DSPACE/DSpaceResources#DSpaceResources-IRCchannel or some other useful explanatory text added?
[22:00] <tdonohue> snail -- DuraSpace runs that. However, it's not just a DSpace resource. It logs #duraspace IRC, which is used for DSpace, Fedora and any other DuraSpace-related IRC chats/meetings.
[22:13] <tdonohue> All (esp mdiggory & grahamtriggs), in regards to today's discussion about Version Numbering. I created a wiki page to begin adding ideas: https://wiki.duraspace.org/display/DSPACE/Thoughts+on+Version+Numbering So, mdiggory & grahamtriggs, please feel free to expand on your ideas around versioning. Once we have thoughts together, we can also forward to lists for comments / continued discussion
[22:16] <snail> tdonohue: that URL isn't working for me...
[22:17] <snail> tdonohue: works now
[22:17] <tdonohue> yea, it seems we may be experiencing some wiki issues. I've had others report similar wiki issues, but it works fine for others (myself included)
[22:33] * grahamtriggs (~grahamtri@cpc2-stev6-2-0-cust333.9-2.cable.virginmedia.com) Quit (Quit: grahamtriggs)
[22:35] * tdonohue (~tdonohue@c-98-228-50-45.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.
