Timestamps are in GMT/BST.
[0:19] * awoods (~awoods@pool-72-66-75-191.washdc.fios.verizon.net) Quit (Remote host closed the connection)
[4:06] -hubbard.freenode.net- *** Looking up your hostname...
[4:06] -hubbard.freenode.net- *** Checking Ident
[4:06] -hubbard.freenode.net- *** Found your hostname
[4:06] -hubbard.freenode.net- *** No Ident response
[4:06] * DuraLogBot (~PircBot@fedcommsrv1.nsdlib.org) has joined #duraspace
[4:06] * Topic is 'Welcome to DuraSpace - This channel is logged - http://duraspace.org/irclogs/'
[4:06] * Set by cwilper on Tue Jun 30 16:32:05 EDT 2009
[6:31] * grahamtriggs (~trig01@80.169.130.178) has joined #duraspace
[7:34] * Tonny_DK (~thl@130.226.36.117) Quit (Quit: Leaving.)
[8:18] * mhwood (~mhwood@2001:18e8:3:171:218:8bff:fe2a:56a4) has joined #duraspace
[8:36] * Dan_Davis (~43f11873@gateway/web/freenode/x-qbwjwixddmpygigr) Quit (Quit: Page closed)
[9:32] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has joined #duraspace
[13:12] * grahamtriggs (~trig01@80.169.130.178) has left #duraspace
[14:50] * cccharles (~cccharles@131.104.62.47) has joined #duraspace
[15:00] * richardrodgers (~richardro@dhcp-18-111-9-121.dyn.mit.edu) has joined #duraspace
[15:00] <richardrodgers> Hey folks - is there commiter mtg today?
[15:01] <tdonohue> richardrodgers: you are an hour early. it's still at 20:00UTC, which is now an hour later for those of us in the USA (cause of daylight savings)
[15:02] <richardrodgers> ah right - forgot about the time change thanks
[15:02] <tdonohue> no problem :)
[15:02] <richardrodgers> I'll call in then
[15:02] * richardrodgers (~richardro@dhcp-18-111-9-121.dyn.mit.edu) Quit (Client Quit)
[15:09] * mdiggory (~mdiggory@cpe-66-74-212-9.san.res.rr.com) has joined #duraspace
[15:54] * keith-noadmin (~keith-noa@lib-kgilbertson.library.gatech.edu) has joined #duraspace
[15:55] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has joined #duraspace
[15:57] * grahamtriggs (~grahamtri@cpc1-stev6-2-0-cust340.9-2.cable.virginmedia.com) has joined #duraspace
[15:58] * caryn_ (~80c8e115@gateway/web/freenode/x-djmvbelnsxfqcfiv) has joined #duraspace
[15:59] <tdonohue> Hi all. Will start the DSpace Developers Mtg here in a minute or so. Here's a link to the Agenda I sent to dspace-devel: https://sourceforge.net/mailarchive/message.php?msg_name=4B9FB866.1030608%40duraspace.org
[16:00] * keith-noadmin is now known as keithg
[16:01] <tdonohue> Ok, may as well get started. First off, I wanted to welcome PeterDietz as an official DSpace Committer. Congrats to Peter!
[16:01] * richardrodgers (~richardro@dhcp-18-111-9-121.dyn.mit.edu) has joined #duraspace
[16:01] <PeterDietz> Thank you, I'm excited
[16:02] <PeterDietz> oops I mean +1
[16:02] <mhwood> [applause]
[16:02] <tdonohue> we're excited to have you join the team!
[16:02] <kshepherd> congrats Peter :)
[16:02] <richardrodgers> Yes welcome Peter!
[16:03] <PeterDietz> I still haven't figured out how to ensure that the pizzas will maintain their "preservation" of being warm, delicious, and not moldy by the time they arrive
[16:03] <kshepherd> we don't want to hear excuses
[16:03] <kshepherd> just make it happen
[16:04] <kshepherd> ;)
[16:04] <grahamtriggs> congrats, and... suggest we send an official email announcement ASAP, as we've 'soft announced' it in the agenda and irc logs!
[16:04] <tdonohue> official will go out later this week...we are waiting as we may end up with a small "group" of new committers to announce
[16:06] <tdonohue> item #2: I'd like to have a face-to-face Committers meeting at OR2010 (likely the monday before the conference) for anyone who will be able to make it to Spain. Preferably I'd like to make it a 1/2 day or even full day meeting to talk more in depth (may even be able to meet up with Fedora committers for some of the time). What do others think of this?
[16:07] <richardrodgers> So you mean Mon 5th July?
[16:07] <tdonohue> yes...that's the likely candidate. though i'm open to suggestions :)
[16:07] <kshepherd> i like the idea
[16:07] <mdiggory> not sure yet if we will travel early to OR or stay later
[16:08] <kshepherd> i was a brand new committer at OR09 and it was a bit tricky tracking everyone down to say hi over the duration of the conference ;)
[16:08] <tdonohue> (from what I hear, the Fedora Committers are also scheduling an all-day mtg for Mon July 5th...so, that might be a prime chance to also have an opportunity to have a small joint meeting for part of the day)
[16:08] <richardrodgers> I'd be fine with that, but I know there is a lot of competition for the pre-conf time, so we should make sure we don't conflict with known other events
[16:08] <mdiggory> agree, I know there will be preconfs we want to be at
[16:08] <PeterDietz> I was planning on going to OR-ten (even before committer status), so that works for me
[16:09] <grahamtriggs> kshepherd: there is a simple answer to that... make new committers where a special hat at the first conference so we can easily spot you :)
[16:09] <kshepherd> heh
[16:09] <mdiggory> hmm jester or dunce
[16:09] <tdonohue> richardrodgers: definitely understood. this is all tentative right now. But, I wanted to start thinking about this now, so that we could even block off a spot before other pre-conf stuff gets scheduled
[16:10] <kshepherd> mdiggory: i was thinking fruit basket
[16:10] <PeterDietz> maybe pizza delivery boy outfit
[16:11] <grahamtriggs> tdonohue: and before we all book our travel / accomodation
[16:11] <tdonohue> so, does anyone have a real preference for pre- or post-OR2010 (i.e. day before or day after)? As DuraSpace is involved with some of the scheduling, I can try to block off a 1/2 day or a day soonish.
[16:12] <tdonohue> grahamtriggs: exactly. I wanted to get this in before travel is booked up :)
[16:12] * kshepherd has no preference and will just do whatever
[16:12] <richardrodgers> not a strong pref at this point
[16:12] <kshepherd> but for the new committers, it might be nice to do it pre-conf
[16:12] <mdiggory> just try not to overlap with preconference workshops...
[16:13] <grahamtriggs> kshepherd: you'll need to leave shortly to get there in time either way
[16:13] <tdonohue> I'll talk to others at DuraSpace involved in the conf planning, and see what time(s) are completely (or mostly) conflict free.
[16:13] <kshepherd> tell me about it :/
[16:13] <richardrodgers> thanks tdonohue
[16:13] <kshepherd> i thought a 13 hour flight was bad.. i think this one will be 20+
[16:14] <tdonohue> Ok. The only other "big topic" I had on the agenda was to try and followup a bit on our "Time Driven Release" proposal & discussion from last week's meeting: http://wiki.dspace.org/index.php/TimeDrivenReleaseProposal#Notes_from_Discussion_on_10_March_2010
[16:15] <tdonohue> I'd like to get to a consensus on how we'd like to manage the 1.7 release especially, so that we can begin working toward that release
[16:16] <tdonohue> keep in mind, we don't need to make "drastic" changes immediately (we can take small steps)...but, it seemed like most of us were in favor of this Time Driven Release process
[16:16] <richardrodgers> I'd say we should shoot for a date no later than 1 year from now, maybe sooner
[16:16] <kshepherd> i cant see that it would hurt to try a time-driven release
[16:17] * grahamtriggs really, really wants to ditch the 1.x / 2.x numbering if we go to time based releases
[16:17] <mdiggory> appropriate committers hat for conference ... http://bit.ly/ayrwJP
[16:17] <mhwood> A year seems long. 3-6 months?
[16:17] <tdonohue> I'll also remind us that it did take 2 years between 1.5.0 and 1.6.0 (guaranteed, 1.5.1 and 1.5.2 ended up being larger releases along the way as well).
[16:18] <richardrodgers> I'm ok with new numbering scheme - provided we can clearly articulate upgrade paths in non-confusing ways..
[16:19] <caryn_> mhwood: +1
[16:19] <mdiggory> I think we need to consider that if the time period is too short for a major release, not much will have changed? (I'm not vested in that assertion)
[16:19] <kshepherd> grahamtriggs: what would be your proposed numbering?
[16:19] <mdiggory> 123456789.0
[16:19] <grahamtriggs> mdiggory: close, we give it handles - 123456789/1, 123456789/2, etc. :)
[16:19] <tdonohue> mdiggory: i'd agree. shorter timeframes will likely equal fewer features in each release. I think anything between 6 mos to a year might be a good to try for 1.7
[16:20] <caryn_> i think 6 months seems like a good time period between releases (of course, that comes from my non-committer perspective)
[16:20] <kshepherd> DSpace 2^π
[16:20] <mdiggory> I'm not too worried about version numbers... accept the dreaded 2.0 oversell...
[16:20] * jat_ysu (~jatrimble@pool-70-17-174-165.pitt.east.verizon.net) has joined #duraspace
[16:20] <grahamtriggs> kshepherd: I'm quite comfortable with the year / month version numbering that the likes of Ubuntu use (they don't seem to have too many problems with it!)
[16:20] <mhwood> I was thinking successive approximations of e (Knuth already took pi for TeX)
[16:21] <mdiggory> If we go releasing individual modules... we need version ranges that support their incrementation within a major release space
[16:22] <mdiggory> so we might consider something like dspace-api-lang 1.6.0.1
[16:22] <mdiggory> which was an attempt to allow more releases of dspace-api-lang withint he range of dspace 1.6.0
[16:22] <kshepherd> i'd be inclined to go closer to 6mo than a year... important not to overcommit though
[16:22] <tdonohue> Although the version numbering is interesting, I worry about confusing people to much by jumping from DSpace 1.6 to DSpace 10.09 (if we release in Sept 2010)
[16:23] <mdiggory> DSpace 2010.09.01
[16:23] <richardrodgers> hence my messaging concern - we might dual label for a few releases
[16:24] <grahamtriggs> back to the point of not much changing between releases - I think that's ok from time to time. if you set out timeframes beforehand, you expect that you can't always have the same pace of change in each release
[16:24] <mhwood> DSpace 2010, DSpace XP, DSpace Vista, DSpace 7
[16:24] <tdonohue> what benefit does renumbering really give us? (Other than attempting to avoid 2.0 forever?)
[16:24] <kshepherd> and upgrade paths themselves..? people wondering if they can go straight from DSpace 2010.09.01 to DSpace 2012.09.01 without upgrading to teh the intermediate version?
[16:24] <mdiggory> not too kean on the dated release numbers.... the integration/snapshot releases already do that
[16:24] <kshepherd> documentation solves that, of course.. but i'm sure people will wonder
[16:25] <grahamtriggs> mhwood: DSpace 2010 would work, only if we did annual (or every 2 years) releases
[16:25] <mdiggory> we would end up with 2010.09.01-20100401.ext
[16:25] <jat_ysu> it's still a slippery slope of confusion......Are you on version 1.6 or DSpace 2010
[16:26] <grahamtriggs> tdonohue: it means people always 'know' what they have. You don't have to think... how long ago did 1.6 come out? how many releases have there been since? etc.
[16:26] <jat_ysu> The upgrade path looks funny to the neophyte: "Upgrade from 1.6. to Dspace 2010 following these instructions..."
[16:26] <caryn_> only thing i would add is that it's kind of nice to look at a numbering system, and know approximately where it fits...
[16:27] <caryn_> if we agree to a twice annually upgrade, would it work to do something like 2.1, and 2.2, 3.1 and 3.2, with minor bug fixes as 2.1.1, etc ?
[16:27] <tdonohue> To be honest, it seems like this renumbering could be more problems than it'd be worth right now.
[16:27] <kshepherd> to slightly change the topic: i'd like to know a bit more about asynchronous releases.. have not worked on any projects that did them
[16:27] <grahamtriggs> and bear in mind that because we already have artefacts in the 1.6 release that are numbered 2.0, there is a very real possibility that a DSpace 2.0 release would comprise of artefacts numbered 1.8.x, 2.0.x and 2.1.x/2.2.x. Anyone want to explain that one? :)
[16:28] <jat_ysu> Oookay...Graham..ya gotta point
[16:28] <mdiggory> ugh... I'm not warming up to this year version number thing.... Maybe for the overall release, but we will have individual components that need to be maintained with their own version histories... if they don't change much in a year, theres really little need to rerelease them with a new number
[16:29] <mhwood> It sounds as though, even if we keep the current scheme, the answer to "which version of DSpace are you running" is going to become a vector.
[16:29] <grahamtriggs> mdiggory: artefacts / components... dare I say it, modules... could go a different way. think Ubuntu!
[16:29] <mdiggory> Yes, in fact, for the overall release mabe the year would suffice to disambiguate it from the individual component version numbers
[16:29] <grahamtriggs> Ubuntu release is 9.10, doesn't make X.org 9.10, Gnome 9.10, Kernel 9.10, etc.
[16:30] <mdiggory> correct
[16:30] <kshepherd> ok
[16:30] <kshepherd> so we can have DSpace 2011, shipping with dspace-api 1.7?
[16:30] <kshepherd> (etc)
[16:31] <tdonohue> ok. can we take a small step back for a moment. we jumped from scheduling 1.7 to different number schemes, etc. First off, no matter what we want to call the next release (1.7 or whatever), do we vote to schedule this release for 6 mos (Sept 2010)? 1 year (Mar 2011)?
[16:31] <mdiggory> true... that is the thought, that would also allow for managing module versions individually rather than in one large swoop... but I wonder about maintence releases then...
[16:32] <mhwood> 6 months. Smaller change bundles: easier upgrades.
[16:32] * kshepherd tends to prefer closer to 6 months
[16:32] <caryn_> 6 months would be nice!
[16:32] <mdiggory> I think that 6mos is very ambitious. We are just ramping up on 1.6. installs and havn't even gotten feedback on significant issues with it
[16:32] <kshepherd> and we might just have to get pickier about what makes it in :)
[16:33] <grahamtriggs> I'm going to be awkward and suggest that if we set 6 months as the future interval, we don't set the NEXT release to exactly 6 months from now - give ourselves a little time to get things in order
[16:33] <richardrodgers> I agree with mdiggory - 6 months might be a good goal, but off the bat ambitious
[16:33] <caryn_> grahamtriggs: +1 would be good to get the community ready for this new system!
[16:34] <caryn_> (in addition to ramping up for the development)
[16:34] <tdonohue> I'll actually I admit that a release in Sept/Oct seems a bit ambitious to me as well right now.
[16:34] * grahamtriggs thought I was being awkward, and everyone else said the same thing whilst I was typing
[16:34] <richardrodgers> yes grahamtriggs - the frequency can be adjusted, it's the new approach we must embrace
[16:35] <tdonohue> we could also honestly just say the next release will be _____ (whether that is Dec 2010, Jan 2011, whatever), and set frequency after that
[16:35] <mdiggory> I'm more for 1 year releases, it leaves room to meet and plan about what changes would go into it, leaves room for initiatives to make dramatic improvements still and coincides with major conference events like OR.
[16:35] <caryn_> from an academic perspective, setting a goal for relases of dec, then june is nice - it coincides with the breaks
[16:35] <grahamtriggs> true, we can adjust the frequency if necessary... I think we should set out a goal though, just that it is separate from us saying when that frequency kicks in
[16:36] <mdiggory> during the year minor updates could be released that can be provided via maven updates.
[16:36] <mhwood> Also means a lot of people will wait 1 year for something that goes in tomorrow.
[16:36] <mdiggory> no
[16:36] <mdiggory> thats not true
[16:37] <mdiggory> minor maven updates provide new maintence features
[16:37] <tdonohue> So, how about saying -- 1.7 (or whatever we call it) will be released in Dec 2010. After that, we will strive for releases every June and Dec (every 6 mos). If we get to Dec 2010 and feel that frequency is too ambitious, we can rethink then.
[16:37] <mdiggory> we set rules on how dramatic / backward compatable those minor updates can be
[16:37] <caryn_> tdonohue: +1
[16:37] <mdiggory> tdonohue: -1
[16:37] <mdiggory> ;-0
[16:38] * tdonohue thinks there's always got to be one -- looking at you mdiggory :)
[16:38] <grahamtriggs> tdonohue: +1
[16:38] <mdiggory> ducks...
[16:39] <mdiggory> ok, I accept the 1.7 (or whatever we name it) in Dec, but I'm just not for 6mo major release intervals
[16:39] <mhwood> tdonohue: +1. That's almost a year the first time, and we'll have that experience later.
[16:39] <grahamtriggs> ..ish. I'll admit, I was going to suggest February as the first release, but if we're happy with Dec...
[16:40] <mdiggory> TBH grahamtriggs I'd rather not swamp my holiday with DSpace release process
[16:40] <tdonohue> mdiggory: as I said, we can reanalyze in Dec if we've come up with something better. I'm just trying to get us to set some sort of goal now :)
[16:40] <kshepherd> +1 to "release and re-evaluate in Dec"
[16:40] <mhwood> mdiggory: I worry about having to ask people *which* DSpace 1.7 they are having trouble with.
[16:41] <tdonohue> what do others think of Dec 2010 for 1.7, and re-evaluate then? We can even leave off an exact frequency of 6 mos after that, if that seems too ambitious right now.
[16:41] <tdonohue> I count +4 right now... and a tentative from mdiggory
[16:42] <kshepherd> i admit my preference for 6mos might be unrealistic
[16:42] <richardrodgers> tdonohue: +1
[16:43] <tdonohue> ok. Sounds like we have a date for 1.7 (or whatever we call it). Dec 2010 it is. We'll re-evaluate then
[16:44] <mhwood> How will the community receive the interval eventually decided? Do we know enough to say?
[16:44] <tdonohue> now...we can return to one of the other side discussions...number schemes or asynchronous release?
[16:44] <mhwood> Yeah, December 2010 sounds okay.
[16:44] <kshepherd> i thought asynchronous releases sounded cool, but mhwood just brought up a good point
[16:44] <mdiggory> I just come back to grahamtriggs suggestion of a month or so later
[16:45] <tdonohue> mhwood: we probably don't know enough to say. Though, I have heard generally that people (at least in the DSpace Outreach Group) like the idea of us scheduling our releases out in advance (no matter the timeframe)
[16:45] <caryn_> mhwood: we're just testing intervals now, right?
[16:45] <kshepherd> 20:40 < mhwood> mdiggory: I worry about having to ask people *which* DSpace 1.7 they are having trouble with.
[16:45] <mdiggory> mhwood: which DSpace 1.7 would be based on a simple list of dependencies installed.
[16:45] <mhwood> DSpace(core=>1.7.2, api=>1.7.1, xmlui=>1.7.3)
[16:46] <mdiggory> What is installed can be presented in a Control Panel in the admin UI.
[16:46] <caryn_> mdiggory: i like that idea! would also be nice to add some sort of indication if an upgrade and/or patch is available...
[16:47] <caryn_> that might be a little ambitious, though (indications in admin ui)
[16:47] <mhwood> caryn_: you can write that part
[16:47] <grahamtriggs> There is only one DSpace 1.7 / DSpace 10.12 - that is, the overall distribution. No individual artefact that is part of the release - however they are numbered - will be called 'dspace'.
[16:48] <mdiggory> caryn_: thats how Atlassian does all this... Confluence, JIRA, all are OSGi applications.... download and install a plugin is done via a UI.
[16:48] <mdiggory> they open sourced this framework....
[16:49] <caryn_> interesting - i was just thinking about some sort of "hey, there's a new release/patch to check out", not necessarily a "install me" button
[16:49] <mdiggory> http://confluence.atlassian.com/display/PLUGINFRAMEWORK/Plugin+Framework+Developer+Documentation
[16:49] <tdonohue> mdiggory: although I love that general idea (installing/upgrading plugins via UI)... I really wonder how easy it would be to "get there" (i.e. not sure if it's something we'd be able to do immediately for next release)
[16:49] <mdiggory> but thats a wild tangent....
[16:50] <mdiggory> a good "special topics" meeting
[16:50] <tdonohue> yes. definitely
[16:50] <kshepherd> yeah
[16:50] <grahamtriggs> mdiggory: if we're going on that tangent, worth bearing in mind the Alfresco variation: http://wiki.alfresco.com/wiki/AMP_Files
[16:50] <mhwood> On version number format: is there any interaction with Maven on this? Maven is pretty firm about doing things its own way.
[16:50] <mdiggory> perhaps we can get some guests fromt eh Fedora side to share their point of view
[16:50] <mdiggory> since they are focusing on OSGi lately
[16:51] * tdonohue wrote himself a note about special topics mtg on installing plugins via UI -- will add to list later
[16:52] <mdiggory> tdonohue: I think the first step would be to get our house in order....
[16:53] <tdonohue> mdiggory: agreed. just adding to an ever increasing list of "special topics" not saying this will happen *soon* :)
[16:53] <mdiggory> project structures, release schedules, etc all good important activities to make our development team more comfortable with change.
[16:55] <tdonohue> I'm surprised there's no more discussion on the release numbering? are we generally satisfied with "1.7"? (we don't need to decide right now...just surprised it's gotten quiet)
[16:56] <richardrodgers> Since we don't need to announce soon - can be deliberate further?
[16:56] <mdiggory> I thought we agreed to put that decision off
[16:56] * kshepherd is no longer prepared to have an opinion ;)
[16:56] <tdonohue> yea, we can table it then.
[16:56] <richardrodgers> be -> we
[16:57] <mdiggory> I'm thinking that we need to discuss async release of modules more before we decide on the distribution release id
[16:57] <mhwood> Yes, needs more think time.
[16:58] <tdonohue> FYI: I've been keeping a list of potential "Special Topics" meetings on the Wiki: http://wiki.dspace.org/index.php/Special_Topics If you have more ideas, please add some notes to the list (that way there's a list for us to chose from for April's meeting)
[16:58] <tdonohue> mdiggory: I'd appreciate if you can add a few notes there about async release of modules -- that'd be good to discuss more in depth
[16:59] <mdiggory> yes, I can
[16:59] * kshepherd has to go soon
[16:59] <tdonohue> Other than that. we're nearing the top of the hour, so I won't bring up any more topics today. :)
[16:59] <tdonohue> have a nice evening, all. meeting is closed.
[17:00] <richardrodgers> thanks all & welcome again Peter - bye
[17:00] * richardrodgers (~richardro@dhcp-18-111-9-121.dyn.mit.edu) Quit (Quit: richardrodgers)
[17:00] <mdiggory> Cheers
[17:00] <kshepherd> cheers all
[17:00] <mhwood> Thanks, everybody.
[17:01] * jat_ysu (~jatrimble@pool-70-17-174-165.pitt.east.verizon.net) Quit (Quit: Leaving)
[17:03] * keithg (~keith-noa@lib-kgilbertson.library.gatech.edu) Quit (Quit: knocked out by robots)
[17:21] * PeterDietz (~PeterDiet@ACK5859s3.lib.ohio-state.edu) has left #duraspace
[17:53] * caryn_ (~80c8e115@gateway/web/freenode/x-djmvbelnsxfqcfiv) Quit (Quit: Page closed)
[17:57] * tdonohue (~tdonohue@c-98-228-50-55.hsd1.il.comcast.net) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.