Timestamps are in GMT/BST.
[6:28] -niven.freenode.net- *** Looking up your hostname...
[6:28] -niven.freenode.net- *** Checking Ident
[6:28] -niven.freenode.net- *** Found your hostname
[6:28] -niven.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:59] * elschlomo_ (4e2a62d3@gateway/web/freenode/ip.78.42.98.211) Quit (Quit: Page closed)
[12:58] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[13:59] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[14:01] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[14:03] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) has joined #duraspace
[15:02] * mhwood (~mhwood@2001:18e8:3:10ab:7a2b:cbff:feb4:89a9) Quit (Ping timeout: 240 seconds)
[15:10] * mhwood (~mhwood@mhw.ulib.iupui.edu) has joined #duraspace
[15:13] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Ping timeout: 240 seconds)
[15:39] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) has joined #duraspace
[18:19] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Read error: Operation timed out)
[18:26] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:26] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:28] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:28] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:29] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:29] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:30] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:30] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:32] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:32] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:32] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:33] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:34] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[18:34] * GargantuaSauce (~Gargantua@142.176.125.39) Quit (Max SendQ exceeded)
[18:35] * GargantuaSauce (~Gargantua@142.176.125.39) has joined #duraspace
[19:35] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) has joined #duraspace
[19:54] <tdonohue> Hi all, reminder that at the top of the hour the DSpace Developers Mtg starts here. (Yes, it's an hour earlier now in USA/Canada after DST ended). https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-09
[19:54] * PeterDietz (~PeterDiet@peterdietz.lib.ohio-state.edu) has joined #duraspace
[19:54] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:00] <tdonohue> welcome all, it's time for the weekly DSpace Developers Mtg. Today's agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-09
[20:01] <tdonohue> we'll start things off by returning to our JIRA Quick Reviews for the first 10-15mins. Here's our list of to-be-reviewed items: https://jira.duraspace.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+DS+AND+resolution+%3D+Unresolved+AND+Key%3E%3DDS-886+ORDER+BY+key+ASC
[20:01] <kshepherd> morning *
[20:01] <tdonohue> hmm...is kompewter on vacation today, PeterDietz? :)
[20:02] <PeterDietz> lemme kick it.
[20:02] <tdonohue> cool, thanks! (it's just so very useful for these Jira reviews)
[20:02] * kompewter (~kompewter@peterdietz.lib.ohio-state.edu) has joined #duraspace
[20:02] <tdonohue> well, first up on our JIRA quick review, DS-886
[20:02] <kompewter> [ https://jira.duraspace.org/browse/DS-886 ] - [#DS-886] DSpaceControlledVocabulary always returns an emtpy list - DuraSpace JIRA
[20:03] <kshepherd> i havne't tested the controlledvocab authority plugin since i first committed it (note: i didn't write it, but i did test and commit it)
[20:03] <tdonohue> looks like this one already has a patch -- anyone want to volunteer to review it & report back?
[20:03] <kshepherd> yep
[20:03] <kshepherd> i'll assign to me now
[20:04] <tdonohue> cool, sounds great, kshepherd! thanks. Ds-886 should be assigned to kshepherd
[20:04] <tdonohue> next up, DS-887
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-887 ] - [#DS-887] Move DSpace "Library" Dependencies to new module. - DuraSpace JIRA
[20:04] <tdonohue> oh, this looks like an mdiggory "placeholder"...we'll skip it for now (as he's not here)
[20:04] <tdonohue> next up, DS-888
[20:04] <kompewter> [ https://jira.duraspace.org/browse/DS-888 ] - [#DS-888] file description at UploadStep - DuraSpace JIRA
[20:05] <PeterDietz> hmm, is this a bug? There's no description
[20:05] <kshepherd> i think "fileDescription will never fill with the request parameter description" is hte symptom
[20:06] <tdonohue> yea, I think that's the full description, as kshepherd says. Looks like this could use a quick investigation. Any volunteer?
[20:06] <kshepherd> and the code looks bad
[20:06] <mhwood> Sure enough, if we got nothing, it fetches a different parameter and drops the result in the garbage.
[20:06] <kshepherd> request.getParameter() returns a value
[20:06] <kshepherd> yeah, like mhwood said, that value gets dropped in the garbage ;)
[20:06] <kshepherd> needs to be assigned to fileDescription!
[20:06] <kshepherd> looks simple enough
[20:07] <tdonohue> yep, anyone want to claim and fix then?
[20:07] <mhwood> I can take that one.
[20:07] <tdonohue> thanks mhwood! Ds-888 claimed by mhwood
[20:08] <tdonohue> (Oh, sidenote -- remember, bug fixes should now be applied to both Trunk & the 1.8.x branch -- just in case we decide to do a 1.8.1)
[20:08] <tdonohue> next up, DS-889
[20:08] <kompewter> [ https://jira.duraspace.org/browse/DS-889 ] - [#DS-889] file upload via url. - DuraSpace JIRA
[20:08] <kshepherd> interesting
[20:09] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) has joined #duraspace
[20:09] <mhwood> We need to look at a long list of dependency versions anyway.
[20:09] <kshepherd> yeh..
[20:09] <tdonohue> this is definitely a 'new feature'. Do folks think this would be interesting to add (in post-18.x)?
[20:10] <kshepherd> it'd get a +1 from me, but would we want an extra "confirm" step so the user doesn't blindly assume that the get-by-http returned the right bitstream?
[20:10] <PeterDietz> I don't have a direct use-case in mind for the upload-from-url, but I do like the idea of it.
[20:10] <tdonohue> that sounds logical, kshepherd (I admit, I haven't looked at the implementation here yet -- so it surely could use eyes)
[20:10] <kshepherd> seems like picking a file from your local disk and uploading it is an action where you can feel safe you've got "the right file"
[20:10] <PeterDietz> i.e. if you entered entered a pre-metadata such as entering a pubmedID, and then it figures out how to fetch the object from there
[20:10] <kshepherd> whereas pasting a URL in a box... a little more abstract, might get the wrong thing uploaded in your name
[20:11] <kshepherd> PeterDietz: yes, that'd be extra-nice too
[20:12] <tdonohue> I'd be +1 this idea as well. any volunteer to look at the code, etc?
[20:12] <kshepherd> *crickets*
[20:12] <PeterDietz> I think I'm interested in this upload via url code. So I'll look in to it
[20:13] <tdonohue> cool. thanks. PeterDietz will claim Ds-889 and investigate.
[20:13] <PeterDietz> I'd probably want some feedback from some UI type of people to say when we should present uploadURL, and how to enable/disable
[20:14] <tdonohue> yep, makes sense PeterDietz. I'm sure we'd all be willing to help test things, etc. if you can get the ball rolling
[20:14] <tdonohue> ok, we'll stop JIRA review there for today, as we are now ~15mins into the meeting.
[20:15] <tdonohue> Next up is just a big congrats to us all on 1.8.0! (I see robint isn't here right now, but he deserves major kudos!)
[20:15] <kshepherd> robint++
[20:15] <mhwood> What he said.
[20:16] <PeterDietz> robint++, I wonder if he's taken vacation from all his hard work.
[20:16] <tdonohue> yea, it looks like 1.8 has been quite popular so far. we've been averaging around 150 downloads per day from SourceForge since the announcement on Monday.
[20:17] <tdonohue> It'll be interesting to hear once the first institution has upgraded to 1.8
[20:17] <kshepherd> we (auckland) will be doing so very shortly
[20:17] <kshepherd> we tend to upgrade early :)
[20:18] <tdonohue> cool. let us know. I know DuraSpace always likes to announce who is (seemingly) "first" ;)
[20:18] <hpottinger> we have a stated target of December, but I'm shooting for earlier
[20:18] <PeterDietz> also I have a thanks/shout-out to kshepherd for testing solr bundleNames, and for Kevin Van de Velde for lots of work building that feature. I was impressed by his quick iterations
[20:18] <mhwood> I've begun pulling together an upgrade here but I'm not sure when it will be ready.
[20:20] <tdonohue> ok, guess we'll move along here...you'll notice I've changed the format of our Agenda slightly (at least you may have noticed). https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-09
[20:20] <kompewter> [ DevMtg 2011-11-09 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2011-11-09
[20:21] <tdonohue> There's a new section for "Individual Status Updates". If you have *anything* you'd like to report to us all prior to a meeting, please feel free to edit this section & add it in.
[20:22] <tdonohue> I've restructured this slightly to match how we now run our DuraSpace internal meetings -- we try to avoid too much "status updates" which can be reported more easily offline, and leave more meeting time for discussion & Q&A, etc.
[20:22] <hpottinger> newFormat++
[20:23] <PeterDietz> one thing I learned from DLF 2011 Fall Forum in Baltimore was that lots of people "have been meaning to do TDD Test Driven Development but ...".. So they (Stanford Library Web Team) recommended just requiring Tests along with all new code.. and sure enough, all of your code will eventually be nice and tested
[20:24] <tdonohue> so, this isn't a drastic change for us, but hopefully it will make our meetings more "productive". If anyone has other ideas they'd like to try out, please feel free to suggest them (either now or later on offline)
[20:24] <tdonohue> PeterDietz -- is this a separate topic here? Are you suggesting we push for TDD in our patches?
[20:25] <hpottinger> mhwood has been trailblazing that a bit, I think
[20:25] <tdonohue> aha. ok
[20:26] <tdonohue> Next thing to just mention -- I've started a new "Discussion List" page of topics we really just need to tackle. Please add to this. Currently it's just what I can "remember" and my memory may have overlooked something: https://wiki.duraspace.org/display/DSPACE/DSpace+Developers+Discussion+List
[20:26] <kompewter> [ DSpace Developers Discussion List - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DSpace+Developers+Discussion+List
[20:26] <mhwood> Trying to. I need to get back to porting the test framework out of dspace-api so that it can be used throughout. Then I can go back to several JIRAs that stalled awaiting test classes that can work....
[20:27] <tdonohue> +1 to that work mhwood. It's much needed, thanks
[20:28] <hpottinger> mhwood: this is an area I'd be interested in helping with, not sure where I'd fit in, but just holler if you need eyes on something
[20:28] <mhwood> Thanks, will remember that.
[20:29] <tdonohue> Last topic I have on the agenda. It's a big question, and we are a smallish group today, but I'd still like to discuss/brainstorm it out. "What do we want to call the next version of DSpace?"
[20:30] <tdonohue> For those who were at the OR11 Developers Meeting, we came up with several brainstorms -- calling it "3.0", "2012", "12" (short year), or even "9" (drop the "1." in 1.9). Just curious if anyone has thoughts here
[20:30] <mhwood> 3.0.0 if it has breaking architectural changes.
[20:31] <kshepherd> on this topic, has anyone noticed the backlash against firefox's new versioning/release strategy?
[20:31] <mhwood> Besides my own backlash? :-)
[20:31] <kshepherd> i'm seeing a lot of people complain about the constant major version jumps... possibly because FF releases so often, and because we were used to seeing X.y.z for so long
[20:32] <hpottinger> I like 3.0, gets the job done, leaps past all the 2.0 baggage
[20:32] <tdonohue> yea, I've heard that too -- but I always attributed it to the rapid release cycle + major version jumps combined
[20:32] <kshepherd> we don't release every month or two so i don't think we are at quite the same risk, but it was interesting for me to see these reactions
[20:32] <kshepherd> (since we'd discussed their potential at OR11..)
[20:33] <mhwood> Eh, FF 7.0.1 -> 8.0.0 looks unchanged, but I've been trained to expect it to mean things like "major rearrangement of the UI" and "your third-party plugins WILL break".
[20:34] <kshepherd> yeh, FF seems pretty loosey-goosey with their major version jumps
[20:34] <tdonohue> personally, my current thoughts for DSpace are to think about a *new major release each year* strategy. So, in 2012, we'd do a "3.0" (possible bug fix releases 3.1, 3.2, etc), 2013 would bring 4.0, etc etc. But, I'm curious if others think this is a good idea or not.
[20:34] <kshepherd> and that was one of the topics we discussed at OR11, right? whether we can just go to 3.0 without actually making the huge architectural changes people expect in a major version jump
[20:35] <PeterDietz> for dspace name, I'd prefer sticking with 1.X and more or less ignore that there is a 1 at the front. Thus in my head, the next three versions are 9, 10, 11
[20:35] <kshepherd> but i think we got over that in a one-off dose of pragmatism
[20:35] <stuartlewis> If we go for 3, would people expect something big?
[20:35] <tdonohue> yes, it was kshepherd. My view is we go to 3.0 no matter what (doesn't require major architectural changes, but it does free us up to make major changes if we want to)
[20:36] <mhwood> Well, maybe it's time to bite the bullet and pull in some of those major changes. There are certainly enough proposals written up. And many of those are now sized about right.
[20:36] <aschweer> I think "my" librarians just care about "there's been a new DSpace release", I don't think they mind what the version number is
[20:36] <hpottinger> anybody sitting on something big that would warrant a major version jump? :-)
[20:36] <kshepherd> tdonohue: yeah i'm +1 on that too
[20:36] <kshepherd> tdonohue: just rehashing for everyone's benefit ;)
[20:36] <mhwood> End users don't care but developers expect versions to mean something.
[20:36] <PeterDietz> bitstream level metadata would be big enough in my head, bitstream versioning, bitstream relationships
[20:36] * robint (522925f2@gateway/web/freenode/ip.82.41.37.242) has joined #duraspace
[20:37] <tdonohue> stuartlewis -- could be. My point is that we are stagnating at "1.x.x" cause we seem to be scared of major changes. I wonder if we moved to a "we will do a major version each year" model, if that frees us up more to make major changes each year.
[20:37] <robint> Hi all, apologies for being late
[20:37] <kshepherd> i think it was Jonathan (Markow) who reminded us that we as programmers might be attaching too much significance to the numbers
[20:37] <tdonohue> hi robint -- we are discussing "what do we call the next version of DSpace"
[20:37] <kshepherd> that it's ok to go to 3.0 without a good reason
[20:37] <mhwood> I think we've been clearing off the workbench for those major changes. Have we done enough now to make one or two big breaks?
[20:38] <tdonohue> kshepherd -- yes, you have a good memory. that's what I recall as well
[20:38] <hpottinger> kshepherd: my notes agree with your recollection
[20:38] <PeterDietz> Linus Torvalds said whats the point of being dictator if I can't even choose which color to paint the bike shed. (when he jumped linux kernel to 3.x, with no major new feature)
[20:38] <kshepherd> and richard jones made the good "bike shed" argument as to why we were supposed to stop talking about version numbers and get back to dspace dev ;)
[20:38] <kshepherd> PeterDietz: heh, exactly
[20:40] <mhwood> OTOH if we're going to do a major release then let it be a *major release*. There are breaking changes we've been wanting to do (sort of) for some time but haven't done. Pick one?
[20:41] <aschweer> we could just go to year-based -- no confusion around major changes or not...
[20:41] <mhwood> Slaying DCValue alone might be worth a major release.
[20:41] <kshepherd> mhwood++
[20:41] <tdonohue> +1 mhwood
[20:43] <mhwood> Heh, we might be entering a period of frequent major releases because we have that many things we've been needing to break.
[20:43] <tdonohue> so, do we want to do a quick poll here. Where do we all stand here? Do we stay at 1.x.x until a major change happens? Do we just say we are going to 3.0 no matter what (and hope a major change or two happens)? Something else?
[20:43] <stuartlewis> 3.0 +1
[20:43] <kshepherd> i'm +1 on 3.0 no matter what, but i'm also fine if that happens to be a major release (dcvalue, etc)
[20:43] <aschweer> 3.0 +1
[20:43] <aschweer> and kshepherd +1
[20:44] <mhwood> 3.0, would prefer that it earn the label but we need to move on in any case.
[20:44] <tdonohue> 3.0 +1 - I'm in agreement with kshepherd
[20:44] <hpottinger> 3.0 +1, kshepherd +1, mhwood +1
[20:44] <stuartlewis> *properly* deprecating DCValue would be enough to warrant a 3.0 in my eyes.
[20:44] <PeterDietz> +0 I'm fine with either way, no personal preference
[20:44] <stuartlewis> s/deprecating/removing
[20:44] <kompewter> stuartlewis meant to say: *properly* removing DCValue would be enough to warrant a 3.0 in my eyes.
[20:44] <tdonohue> +1 stuartlewis
[20:45] <kshepherd> it's been a long time coming ;)
[20:45] <kshepherd> and will probably break plugins, curation tasks, addons, etc
[20:45] <kshepherd> which makes it "major" imho
[20:45] <tdonohue> agreed
[20:46] <mhwood> And if done the right way, should move us along the architectural path on which most seem to generally agree.
[20:47] <tdonohue> I think if we made any decisions ways to more easily install third-party plugins (whether that goes towards the 'async releases' concept or not), that could also warrant a 3.0 as it'd be a significant change as well -- this is something I'm quite interested in.
[20:47] <tdonohue> ugh -- I worded that oddly, but hopefully you get the idea ;)
[20:47] <mhwood> So one of those is v3 and the other v4, perhaps. Now we just need to schedule 'em.
[20:48] <tdonohue> yep. In my mind, I'd like to just say: We will do 3.0 in 2012 (likely again Oct 2012? or sometime in fall/winter). 4.0 would be in 2013 (one year after 3.0)
[20:48] <aschweer> tdonohue +1
[20:49] <aschweer> (sorry, I need to run off to another meeting -- bye all)
[20:49] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:49] <hpottinger> tdonohue +1
[20:49] <mhwood> Well, I meant "schedule big change X for 3.0 and big change Y for 4.0".
[20:49] <tdonohue> yea, I agree with that too mhwood :) Just pointing out that first we may want to know approx when 3.0 and 4.0 will appear.
[20:50] <mhwood> A year to accomplish massive breakage and recover seems reasonable.
[20:50] <tdonohue> I'd likely vote for DCValue changes for 3.0. Better Third party-plugin support may be more like 4.0 (unless we find it's easy to fit in quickly into 3.0)
[20:51] <PeterDietz> 3.1.0 is also allowed to add new features, but 3.1.1 is not?
[20:51] <mhwood> That schedule, combined with our current general release scheduling, means one minor release between major releases. Okay?
[20:51] <mhwood> PeterDietz: that's traditional and what I would hope to see.
[20:52] <tdonohue> PeterDietz -- I'm actually implying that we move away from 'a.b.c' versioning, and instead just do 'a.b'. So, it would be *3.0* and not 3.0.0. And bug fix releases would be 3.1, 3.2 (rather than 3.0.1 and 3.0.2)
[20:52] <tdonohue> but, that's just my personal opinion. if others disagree, I'm ok with 3.0.0
[20:53] <tdonohue> I just think that a versioning sequence of *major.minor* is easier than *major.minor.subminor* -- the latter is what got us into trouble in the past as nothing ever seemed "major" enough
[20:54] <tdonohue> what do others think here? major.minor (e.g. 3.0) or major.minor.subminor (3.0.0)?
[20:54] <kshepherd> i like x.y
[20:54] <robint> me too
[20:54] <kshepherd> don't see a need for .z
[20:55] <robint> It reflects evolutionary approach to development, we don't do total rewrites
[20:55] <kshepherd> as tdonohue says, we really only use two of those numbers anyway
[20:55] <mhwood> Not I, but in the interest of getting out of the bike shed I'm trying to let go.
[20:56] <hpottinger> I'm +0 on minor vs minor.subminor
[20:58] <mhwood> Just as long as it's something numeric that Maven can cope with. If we want to call the next one Jovial Jaguar we'd have to have a number anyway.
[20:58] <tdonohue> so, it sounds like we have a few +1 and a few +0 (if I understood mhwood). I'm +1 going to major.minor, as I feel it allows us to make more rapid changes between versions (obviously we'll still need to build upgrade/migration paths though).
[20:58] <mhwood> Yes, +0
[20:59] * robint_ (522925f2@gateway/web/freenode/ip.82.41.37.242) has joined #duraspace
[20:59] * robint (522925f2@gateway/web/freenode/ip.82.41.37.242) Quit (Ping timeout: 265 seconds)
[21:00] <tdonohue> Ok, well at this point, we have come to a consensus that we want to do 3.0 in 2012. The only outstanding question is whether it's 3.0 or 3.0.0 (though more are leaning towards the former). I will bring this decision/discussion to dspace-commit so others can take part as well
[21:00] <tdonohue> At that, we'll go ahead and close up today's meeting, mostly "on-time". I'll stick around though if anyone has anything else to bring up
[21:00] <kshepherd> cheers all
[21:01] <robint_> tdonohue: I haave a wee question
[21:01] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) has joined #duraspace
[21:01] <kshepherd> i'll be committing a quick'n'easy google geocode curation task to my github curation project soon
[21:01] <tdonohue> go ahead, robint_
[21:01] <robint_> Just rereading the log
[21:01] <tdonohue> richardrodgers -- you are an hour late :) Just closing up the meeting
[21:01] <richardrodgers> damn! sorry
[21:02] <robint_> You mentioned that you thought an x.x scheme would help rapid development
[21:02] <robint_> I'm a bit confused
[21:02] <tdonohue> richardrodgers: no prob. it's hard to remember that 20:00UTC is now one hour earlier after DST ended.
[21:02] <robint_> In an x.y scheme would a y release be more than bug fixes ?
[21:03] <tdonohue> in my mind, if we went to "major.minor" versioning (e.g. 3.0), then it'd act similar to this...
[21:03] <tdonohue> 3.0 would be a major version (new features, improvements, potentially major architectural changes, bug fixes)
[21:03] <kshepherd> again, i think we effectively already use x.y, so it doesn't have to be a big shift in how we work
[21:03] <tdonohue> 3.1 would be a bug fix release to fix bugs in 3.0 (no new features)
[21:03] <kshepherd> but we currently prepend a static "major" number, "1", at the front
[21:03] <kshepherd> so we don't use x.y.z right now, we use 1.x.y :P
[21:03] <tdonohue> 3.2 would also be bug-fixes only
[21:04] <tdonohue> 4.0 would be the next major release (new features again, etc.)
[21:04] <tdonohue> kshepherd & I are saying the same thing, just in a slightly different way
[21:04] <tdonohue> does that make more sense, robint_?
[21:06] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) has joined #duraspace
[21:07] <tdonohue> mdiggory forgot about DST as well. :) meeting just ended. 20:00UTC is now one hour earlier in USA
[21:07] * robint_ (522925f2@gateway/web/freenode/ip.82.41.37.242) Quit (Ping timeout: 265 seconds)
[21:07] <mdiggory> Gahhhh
[21:07] * robint (522925f2@gateway/web/freenode/ip.82.41.37.242) has joined #duraspace
[21:07] <mhwood> Speaking of versions, I'd like to see developers look over 'mvn versions:display-dependency-updates' and consider whether we can freshen some of those dependencies.
[21:07] <mdiggory> ok, I'll just have to read up in the logs ;-)
[21:07] <robint> Sorry, suffering laptop woes
[21:07] <PeterDietz> good thing we just assigned lots of things to mdiggory
[21:07] <tdonohue> robint : did you get those earlier messages from kshepherd & I?
[21:07] <mdiggory> To be expected
[21:08] <kshepherd> also, now that robint is here, and more of us are here than at the beginning of the meeting....
[21:08] <kshepherd> robint++ # thanks for 1.8!
[21:08] <robint> tdonohue: yes thanks. I jusstn't wasn't clear if we were now planning on doing more than bug fix releases during the year
[21:08] <tdonohue> yes, robint++
[21:08] <stuartlewis> +1 - thanks Robin :)
[21:08] <mhwood> +1
[21:08] <robint> I'm blushing
[21:08] <stuartlewis> +99 :)
[21:08] <tdonohue> +1.8.0
[21:09] <hpottinger> yup yup robint++
[21:09] * stuartlewis is wondering who the next RC is going to be? :)
[21:09] <robint> Now would be the moment to say "so do you fancy doing the next one too ?"
[21:10] <robint> sync
[21:10] <tdonohue> robint: in my view, we'd still just do *one* major release per year (no matter what numbering scheme we use) -- the others would all be bug-fix only releases
[21:10] <robint> tdonohue: thanks, thats clear
[21:11] <richardrodgers> Cheers Robin - a pint in Edinburgh with your name on it next year!
[21:11] <hpottinger> aye, pint++
[21:12] <robint> I'll happily coordinate that richardrodgers :)
[21:12] * tdonohue wonders if we should stop having an "RC" -- i.e. whether we need to move to RTs (Release Teams). The RC job is getting too "large", even though robint still managed it marvelously with 1.8
[21:12] <tdonohue> pint --> robint
[21:13] <mhwood> Maybe the RT is convened by the RC by asking for deputies or something.
[21:13] <tdonohue> (but that topic -- RC vs. RT we can decide upon next week )
[21:14] <robint> In hindsight I didn't take enough aadvantage of PeterDietz's early offer to be a deputy RC
[21:14] <tdonohue> mhwood -- yea, could be. Just pointing out that one RC is getting too be a "demanding job"
[21:14] <robint> We live and learn
[21:16] <kshepherd> afk, cheers all
[21:16] <PeterDietz> I don't know how helpful I actually freely volunteered myself though. I originally was thinking I'd be able to help tackle the smaller issues before the release, but life became busy, and it showed just how good you were at managing it Robin.
[21:17] <mdiggory> Sounds like a firm reason to hold the next RT planning meeting in the closest pub in Edinburgh
[21:18] <robint> Stop me if I am drifting into next weeks topic, but I think we may need to look at staggering the development a bit more throughout the year
[21:18] <hpottinger> +1 mdiggory
[21:18] <robint> mdiggory: I have some venues in mind already :)
[21:18] <richardrodgers> how do you mean? robint
[21:18] <tdonohue> +1 robint. that would also be helpful. the reason the RC job is so hard is that everything comes in at once... :)
[21:19] <robint> Many of the major features were 'ready' well in advance but not commited until the last moment
[21:19] <robint> I include my Sword Client work
[21:19] <mhwood> Like: set 3-4 "milestones" and ask contributors to commit to having *something* go in at a specific milestone?
[21:19] <tdonohue> RC job goes like this -- wait. wait. wait. wait. oh my, there's the flood of stuff. catchup catchup catchup catchup
[21:20] <tdonohue> mhwood ++
[21:20] <robint> We could try and identify major features and make periodic efforts to get them commited througout the year
[21:20] * tdonohue is noticing we are having a post-meeting adhoc meeting of sorts (which is fine...we actually have more people here now than an hour ago)
[21:20] <robint> I realise this may be wishful thinking though
[21:21] <richardrodgers> I agree with all this - but we have to counterbalance the demands we put on an RC (if it becomes a year-long ordeal!)
[21:21] <tdonohue> robint ++ assumes we can convince ourselves to commit to a deadline & actually meet that deadline though ;)
[21:21] <mhwood> The RC can but ask. The RC can also refuse something that comes in too late and put it off to "next time".
[21:21] <richardrodgers> maybe that's further fuel for the RT idea....
[21:21] <hpottinger> this sounds a bit like the beta milestones idea
[21:22] <mdiggory> smells like integration builds
[21:22] <robint> tdonohue: yep that is probably the biggest problem. Without the finaal deadline it can be difficult to prioritise
[21:22] <tdonohue> richardrodgers: exactly. you posed why I feel the RT is necessary. RC has too much to do now -- it was a bit easier when there were only 5-10 committers. Now, with 23, it's hard to expect one person to manage it all
[21:23] <mdiggory> with some automated interim releases, these test candidates would reduce the breakage that can happen in the release process.
[21:24] <mdiggory> It would also help us achieve a more automated release process that could reduce the effort on the RC's part
[21:24] <mhwood> Automated?
[21:25] <mdiggory> As in using Bamboo and a single account to release periodic builds into sonatype
[21:26] <mdiggory> this would allow us to review the interim releases and catch issues like missing files in jars etc
[21:26] <mhwood> Not a bad idea, but a different issue? We need features to land a few at a time rather than mostly near the end.
[21:26] <tdonohue> mdiggory -- interesting idea, but it still requires us to actually commit our code earlier (and not wait to commit at the last minute)
[21:27] <robint> tdonohue: yes I think getting the code visible and commited needs to be the focus
[21:28] * tdonohue remembers we had this same discussion after 1.7, which made us decide to try "beta releases" with 1.8. But no code ever got committed in time for those "beta releases", so we didn't do them. it's all one big circle :)
[21:28] <hpottinger> maybe a review of patches ready for commit as part of the meeting, kind of like Jira review, but with an eye towards encouraging folks to commit earlier?
[21:28] <mdiggory> http://www.eclipse.org/epp/download.php
[21:28] <kompewter> [ EPP Nightly Package Builds ] - http://www.eclipse.org/epp/download.php
[21:29] <robint> I think its requires the RC/RT to engage with major contributions early and help/push the commit process
[21:29] <robint> Although as tdonohue points out I am sure evry RC thinks this just after release :)
[21:30] <mhwood> Exactly. One needs developers to sign up to contribute by specific points in the release process. The only way that's going to happen is to ask them to.
[21:30] <mdiggory> tdonohue: I understand, but if you have the opportunity to show off your work a little earlier and not get bit at the end, milestone builds are an interesting opportunity to get real community feedback... especially if they can be tested on a demo system
[21:30] <tdonohue> Just to be clear, my point about this same discussion after 1.7 isn't meant to discourage more ideas :) Just pointing out that we tried something in 1.8 that didn't end up working...so we may want to try something else this time around
[21:30] <mdiggory> so the process promotes getting your stuff out earlier because the work will be less later and theres more room for feedback
[21:31] <robint> mdiggory: agreed. I think it can be a two pronged attack, the 'soft' side and the technological approach
[21:31] <tdonohue> mdiggory +1 I agree with the idea completely. Just pointing out that we need to figure out a way to encourage folks to actually get code in before those milestones. Just setting the milestones (as we did with "beta releases" this past year) didn't seem to be enough
[21:32] <hpottinger> sorry guys, this is really interesting, but da boss just wandered in and wants to talk, gotta go
[21:32] * hpottinger (80cea2c6@gateway/web/freenode/ip.128.206.162.198) Quit (Quit: Page closed)
[21:33] <mhwood> I most go too.
[21:33] <mhwood> Or, perhaps, *must* go. :-/
[21:33] * mhwood (~mhwood@mhw.ulib.iupui.edu) has left #duraspace
[21:33] <tdonohue> I like robint's idea of a possible two-pronged approach. But, obviously we can all think on this more and discuss it again more @ next week's meeting
[21:35] <robint> Time to head off myself. Cheers all.
[21:35] * robint (522925f2@gateway/web/freenode/ip.82.41.37.242) Quit (Quit: Page closed)
[21:36] <richardrodgers> Bye all!
[21:36] * richardrodgers (~richardro@pool-173-76-20-234.bstnma.fios.verizon.net) Quit (Quit: richardrodgers)
[22:00] * mdiggory (~mdiggory@rrcs-74-87-47-114.west.biz.rr.com) Quit (Quit: mdiggory)
[22:57] * stuartlewis (~stuartlew@gendiglt02.lbr.auckland.ac.nz) Quit (Quit: stuartlewis)
[22:59] * tdonohue (~tdonohue@c-98-228-58-145.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.