Timestamps are in GMT/BST.
[0:57] * Disconnected.
[0:57] -wolfe.freenode.net- *** Looking up your hostname...
[0:57] -wolfe.freenode.net- *** Checking Ident
[0:57] -wolfe.freenode.net- *** Found your hostname
[0:57] -wolfe.freenode.net- *** No Ident response
[6:47] -asimov.freenode.net- *** Looking up your hostname...
[6:47] -asimov.freenode.net- *** Checking Ident
[6:47] -asimov.freenode.net- *** Found your hostname
[6:47] -asimov.freenode.net- *** No Ident response
[6:47] * DuraLogBot (~PircBot@atlas.duraspace.org) has joined #duraspace
[6:47] * Topic is '[Welcome to DuraSpace - This channel is logged - http://irclogs.duraspace.org/]'
[6:47] * Set by cwilper!ad579d86@gateway/web/freenode/ip.173.87.157.134 on Fri Oct 22 01:19:41 UTC 2010
[6:47] -asimov.freenode.net- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[12:03] * jonathangee (~jonathang@blk-222-249-31.eastlink.ca) has joined #duraspace
[12:21] * mhwood (mwood@mhw.ulib.iupui.edu) has joined #duraspace
[12:37] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) has joined #duraspace
[16:21] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[16:24] * eddies (~eddies@cm209.epsilon173.maxonline.com.sg) has joined #duraspace
[16:24] * eddies (~eddies@cm209.epsilon173.maxonline.com.sg) Quit (Changing host)
[16:24] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[16:34] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[16:35] * eddies (~eddies@cm209.epsilon173.maxonline.com.sg) has joined #duraspace
[16:35] * eddies (~eddies@cm209.epsilon173.maxonline.com.sg) Quit (Changing host)
[16:35] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[16:47] * eddies (~eddies@unaffiliated/eddies) Quit (Quit: Leaving.)
[17:05] * eddies (~eddies@cm209.epsilon173.maxonline.com.sg) has joined #duraspace
[17:05] * eddies (~eddies@cm209.epsilon173.maxonline.com.sg) Quit (Changing host)
[17:05] * eddies (~eddies@unaffiliated/eddies) has joined #duraspace
[18:55] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has joined #duraspace
[19:57] * bollini (~chatzilla@host119-68-dynamic.11-87-r.retail.telecomitalia.it) has joined #duraspace
[20:00] * kstamatis (5e42133c@gateway/web/freenode/ip.94.66.19.60) has joined #duraspace
[20:00] <tdonohue> Hi DSpace Developers. It's time for our weekly developers meeting. Today's agenda : https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-14
[20:00] <kompewter> [ DevMtg 2013-08-14 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-14
[20:00] <tdonohue> we'll get started with a few Pull Request reviews. https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:00] <kompewter> [ Pull Requests · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pulls?direction=asc&page=1&sort=created&state=open
[20:01] <tdonohue> Today we start up at #210 : https://github.com/DSpace/DSpace/pull/210
[20:01] <kompewter> [ [DS-1269] EmailService to encapsulate the sending of mail by mwoodiupui · Pull Request #210 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/210
[20:01] <tdonohue> related to DS-1269
[20:01] <kompewter> [ https://jira.duraspace.org/browse/DS-1269 ] - [#DS-1269] EmailService to encapsulate the sending of mail - DuraSpace JIRA
[20:01] * aschweer (~schweer@schweer.its.waikato.ac.nz) has joined #duraspace
[20:02] * pbecker (5cce51d9@gateway/web/freenode/ip.92.206.81.217) has joined #duraspace
[20:03] <mhwood> Looks like I need to update this a bit. It's not auto-merge-able at the moment.
[20:03] <tdonohue> looks like unfortunately this work (PR#210) is unmergeable / outdated. The idea seems reasonable to me though
[20:03] <pbecker> hello
[20:04] <tdonohue> So, mhwood, you plan to do a (hopefully quick) rebase of this? I like the idea here..would be good to integrate more things in as services in general
[20:04] <mhwood> Yes, I will do that.
[20:05] <tdonohue> ok, sounds good. Let us know when it's ready for more eyes again. We'll move along then for now. (If anyone has additional comments, feel free to add to DS-1269
[20:05] <kompewter> [ https://jira.duraspace.org/browse/DS-1269 ] - [#DS-1269] EmailService to encapsulate the sending of mail - DuraSpace JIRA
[20:06] <tdonohue> next PR to review today, #212 https://github.com/DSpace/DSpace/pull/212
[20:06] <kompewter> [ DS-1360 Porting advanced embargo function to JSPUI by helix84 · Pull Request #212 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/212
[20:06] <tdonohue> related to DS-1360
[20:06] <kompewter> [ https://jira.duraspace.org/browse/DS-1360 ] - [#DS-1360] A porting advanced embargo function to JSPUI - DuraSpace JIRA
[20:07] <bollini> I'm going to finalize the review
[20:07] <tdonohue> ok, sounds good, bollini. I see you have already done a good review here
[20:07] <bollini> just to be clear... I want move on two steps here
[20:08] <bollini> get the pull request merged to establish parity between jspui and xmlui
[20:08] <helix84> bollini: feel free to fork that branch and work on it
[20:08] <bollini> and after review the private item meaning
[20:08] <helix84> sounds great
[20:08] <tdonohue> bollini: yea, that seems good to me too. It would be good to establish parity first
[20:09] <tdonohue> So, let us know if there's anything else you need us to help review, bollini. Otherwise, we can try and find a meeting to talk more about "private items" again, as needed.
[20:09] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) has joined #duraspace
[20:10] <robint> Hi all
[20:10] <tdonohue> ok. I'm gonna move on to one more PR review for today. #213 : https://github.com/DSpace/DSpace/pull/213
[20:10] <kompewter> [ [DS-1390] stage 1: move license, email texts, news out of ConfigurationManager by mwoodiupui · Pull Request #213 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/213
[20:10] <tdonohue> related to DS-1390
[20:10] <kompewter> [ https://jira.duraspace.org/browse/DS-1390 ] - [#DS-1390] DSpace has too many configurations - DuraSpace JIRA
[20:11] <mhwood> I think I addressed the only comment, and since then there's been no discussion.
[20:12] * richardrodgers (~richardro@18.189.38.181) has joined #duraspace
[20:12] <tdonohue> having to refresh my memory here...Ah, this is the one about moving from using ConfigurationManager -> ConfigurationService
[20:12] * tdonohue wow, folks coming out of the woodwork today. Good to see richardrodgers & robint ;)
[20:13] <richardrodgers> hi all
[20:13] <mhwood> Yes, I'm trying to make them more similar so that we can get down to one configuration instead of two.
[20:14] <tdonohue> mhwood: Love the idea. I'm glad you resolved that one "deprecated" comment. I'd be +1 getting this first step in for 4.0 to work towards testing it broadly, etc.
[20:14] <robint> Sorry, bit distracted, Scotland are playing England at football on the tv
[20:15] <bollini> I'm +1 with this refactoring too
[20:15] <mhwood> If there are no objections, I'll push the button.
[20:15] <tdonohue> I'd be in favor of getting #213 in sooner rather than later, as it may affect other pull requests coming in the pipe for 4.0
[20:16] <aschweer> I'm happy for mhwood to push the button on this one :)
[20:16] <bollini> I will prefer to squash
[20:16] <bollini> but it is not absolutely necessary
[20:16] <helix84> speaking of configuration manager/service, is it necessary to have those 4 lines written to stderr every time a command is launched from the command line?
[20:17] <mhwood> 213 is merged.
[20:17] <aschweer> helix84: it has saved me a few times to know that a job started at a specific point. but it might be more useful to write 1 line along the lines of "command X is being launched".
[20:17] <tdonohue> helix84: probably not. Might be worth opening a ticket on that. It is worth knowing though what configs it's loading up...but probably should go to stdout not stderr
[20:18] <mhwood> I too am annoyed by the log messages. It just needs someone to figure out how to quiet them.
[20:18] <richardrodgers> Wanted to lobby for a PR: https://github.com/DSpace/DSpace/pull/265
[20:18] <kompewter> [ [DS-1613] Porting curation task administrative UI to JSPUI by zuki · Pull Request #265 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/265
[20:18] <helix84> tdonohue: surely not stdout, stderr is the right place. but 4 lines is too verbose.
[20:18] <tdonohue> ticket it. Someone will grab it (hopefully). I also don't like our aggressive logging at times.
[20:18] <mhwood> I would say they should be subject to a -verbose option or some such.
[20:19] <bollini> just a general note: it will be nice to have a special section in the release note about deprecation and configuration changes
[20:20] <helix84> sorry for distracting again, but our old friend DCValue came up again today on the lists. Are we going to do something with that one?
[20:20] <bollini> it could be useful if we can agree about label to use to mark the jira issue to pick them fastly at the release time
[20:20] <tdonohue> bollini: I agree. We don't tend to note deprecations as well, but we should likely. Config changes though usually are noted minimally in the Upgrade instructions
[20:20] <tdonohue> richardrodgers: will get to that...just noting I saw your request :)
[20:21] <tdonohue> bollini: care to suggest a JIRA label for that? It seems like a reasonable way to "flag" which tickets cause config changes. I'll also note that we already have a 4.0 Docs area open, so folks are encouraged to update docs immediately as needed as well
[20:22] <bollini> tdonohue: I'm not the right people to make suggestion for word... or you like mispelling ? :-)
[20:23] <helix84> changes-config
[20:23] <helix84> introduces-config-change
[20:23] <bollini> changes-config +1 (it is shortly)
[20:23] <tdonohue> I like "changes-config". Nice and brief. Just need to remember to use it
[20:24] <bollini> ok, I'm trying... and "deprecation"
[20:24] <tdonohue> Ok. I want to step back briefly here and review one more PR (by request of richardrodgers): #265 https://github.com/DSpace/DSpace/pull/265
[20:25] <kompewter> [ [DS-1613] Porting curation task administrative UI to JSPUI by zuki · Pull Request #265 · DSpace/DSpace · GitHub ] - https://github.com/DSpace/DSpace/pull/265
[20:25] <tdonohue> bollini: sounds fine to me. We just need to all try to remember to "label" JIRA tickets appropriately as "deprecation" or "changes-config"
[20:25] <bollini> I have this on my todo but if there are any other ready to test now feel free to jump in
[20:26] <richardrodgers> Pitch: we are doing a lot to restore parity of XMLUI & JSPUI in this release, & Keiji kindly undertook this. Low risk, as all code in JSPUI
[20:26] <tdonohue> Glad to see this work. I probably won't have time to review it myself, but I'd support getting it into 4.0. Good work by Keiji.
[20:27] <robint> This is great for us so i'll definitelt review
[20:27] <richardrodgers> Cool, thanks - I don't have any JSPUIs to work with...
[20:28] <tdonohue> Ok, sounds like we have robint and/or bollini looking at this. Good to hear.
[20:28] <mhwood> Be sure to post +1 on the PR if you approve, please.
[20:29] <tdonohue> +1, I agree...best to make that vote public as much as we can
[20:30] <tdonohue> BTW...before we get to our one agenda item. I just wanted to say, I'm LOVING the activity on GitHub recently. It's been great seeing folks working together to quickly review/approve PRs and get them merged rapidly
[20:30] <tdonohue> So, just want to encourage that to continue.
[20:31] <tdonohue> Ok. So, on to our one main agenda item: 4.0 Schedule (and planning in general)
[20:31] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) has joined #duraspace
[20:32] <tdonohue> So, bollini has suggested a 4.0 Release schedule (on the dspace-release list)
[20:32] <tdonohue> It's been copied into the agenda: https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-14
[20:32] <kompewter> [ DevMtg 2013-08-14 - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/DevMtg+2013-08-14
[20:33] <tdonohue> I just wanted to get us to work towards finalizing a schedule, so that we can notify everyone what the plan is (especially developers who may be working on Pull Requests / new features)
[20:33] <hpottinger> sorry I'm late, just got back from an all-staff meeting
[20:34] <pbecker> For us it would be good to know how much time we have until you need our PR for DOI support.
[20:34] <tdonohue> We had one comment on -release from pbecker (who is here today too) about trying to also set a date for "Last date to create a Pull Request" (or something similar), since we've talked about the "Feature Freeze" as the "Last day to merge code"
[20:34] <bollini> related to this... we should try to be more relaxed with voting procedure. I think that most of us are often too worried to push the merge button without a general review. If the pull request has a sense and don't introduce big changes or architectural changes it is better to have something in the master to refine that lot of things staging on the pull queue (and making difficult the merge...
[20:34] <bollini> ...when approaching the feature freeze)
[20:35] <hpottinger> +1 bollini
[20:36] <tdonohue> +1 bollini. I really like the process that has been going on over the last week (or so). There's been a TON of good activity in GitHub, where essentially after two Committers say "+1", someone immediately merges the PR.
[20:36] <mhwood> I would say submit a PR as soon as you have something testable. Make the changes visible early.
[20:36] <helix84> pbecker: basically if you can get 2 other people to review your PR, it's ready to go
[20:36] <tdonohue> It's also worth noting that now that we have Travis CI auto-building all PRs, you'll be warned (with a yellow button in GitHub) if something actually would significantly break the build process
[20:38] <tdonohue> I think pbecker is asking how long do we need to generally review a PR. For example, if the Feature Freeze is Oct 20, should a PR be in by Oct 13? Oct 6? in order to ensure it gets a review before the Freeze deadline.
[20:38] <bollini> pbecker: the other important thing is: start to talk about the changes that you want make *soon*, also before to write any code
[20:38] <mhwood> Depends on how complex it is, and how much change it introduces.
[20:39] <tdonohue> pbecker: the answer unfortunately is "it depends on the size of the PR". For a large PR (lots of changes/files affected), the earlier the better. Really large PRs should really be submitted several weeks before the Freeze (ideally even before that), as they can take some time to review. Small PRs may just take a few days to review.
[20:39] <helix84> the point is Pascal has already been working on this and asking for comments for several months, maybe a year
[20:39] <mhwood> I would suggest thinking: "how soon can we show something" rather than: "how late is too late".
[20:39] <mhwood> Yes, and I need to respond to him. Soon.
[20:40] <bollini> tdonohue_ ...and how much interest *we* have in it... we should be honest, remember the review work is voluntary
[20:40] <helix84> there are some hard questions we need to answer (because handles are currently so hardwired)
[20:41] <pbecker> I try to get it done as fast as possible, but I think a deadline would help to get it ready for the release. ;-) Even today I don't know if we get it ready in time for the release.
[20:41] <tdonohue> yes, that is very true. As bollini mentions, all the PR reviews are done by volunteers. I don't even have specific time set aside for PR reviews, I just review them as they grab my attention.
[20:42] <tdonohue> pbecker: is there anything you can share early to everyone (on GitHub) that we can potentially comment & help on? It also might be worth sharing to dspace-devel as other collaborators may pop up
[20:43] <pbecker> tdonohue: tried this several times. Did you got my mail from last frieday f.e.?
[20:44] <pbecker> the code i released some month ago on github is not actual any more, but we will release new one as soon as it is ready.
[20:44] <tdonohue> pbecker: yea, I got your email. But I noticed you sent it to a small group (3 committers). The probably with a small subgroup is that if none of us have time to help (which I don't have time right now), it's hard to keep it moving along
[20:44] <helix84> pbecker: BTW I think you should be posting to dspace-devel, even if the same people would be answering. It's easier to find things posted there and link to them.
[20:45] <hpottinger> as far as PR review goes, I find it helpful if I can get people here to "buy in" to the PR, say "yes, we want that" then it makes is much easier to justify (to my boss) me spending time on reviewing the PR
[20:45] <tdonohue> pbecker: in my opinion, you are more likely to get broader attention by emailing dspace-devel, or creating a JIRA ticket & linking to public code somewhere (in GitHub or similar).
[20:45] <pbecker> https://jira.duraspace.org/browse/DS-1535
[20:45] <kompewter> [ [#DS-1535] DOI support for dspace-api - DuraSpace JIRA ] - https://jira.duraspace.org/browse/DS-1535
[20:45] <kompewter> [ https://jira.duraspace.org/browse/DS-1535 ] - [#DS-1535] DOI support for dspace-api - DuraSpace JIRA
[20:46] * aschweer (~schweer@schweer.its.waikato.ac.nz) Quit (Quit: leaving)
[20:47] <pbecker> I don't want to take the attention away from the release schedule. I'll send the mail from frieday to dspace-devel tomorrow.
[20:47] <helix84> pbecker: I think the asynchronous registering as you suggested is the way to go
[20:48] <tdonohue> pbecker: Thanks. I admit I forgot about Ds-1535, cause it hasn't gotten any recent updates (and when a ticket is updated, an auto-email is sent to dspace-devel -- which is usually what grabs my attention)
[20:48] <helix84> pbecker: also, if we want to be independent of particular external identifiers, we need a REAL internal unique object identifier. The combined id+resourcetype columns could serve this purpose.
[20:49] <tdonohue> Ok. going back to the 4.0 schedule. Are there any suggestions / counter-proposals / comments on bollini's recommended deadlines? Is this the schedule we'd like to adopt?
[20:49] <helix84> no objections from me
[20:50] <tdonohue> (My only tweak, which I mentioned...is that I think the Testathon should be 1-2 weeks. I think it was only Nov 5-6 in the original proposal)
[20:50] <richardrodgers> Testathon window seems a little small...
[20:50] <hpottinger> +1 1-2 week testathon
[20:50] <bollini> helix84: we are thinking about UUID... we have started to use it in dspace-cris
[20:51] <tdonohue> And, we need to make sure everyone is clear that "Feature Freeze" = "Last day to accept/merge a Pull Request" (and that PRs really need to come in weeks before that, especially large ones)
[20:51] <helix84> bollini: anything's good with me, as far as we have _something_
[20:51] <bollini> have you read my last reply to the scheduling?
[20:52] <hpottinger> was there a discussion of last date for PRs?
[20:52] <tdonohue> bollini: yea, I saw your last email...did I misunderstand something there?
[20:53] <mhwood> I think the idea of the short "official" Testathon was to focus attention on it, and that activity will taper off naturally anyway after a few days.
[20:53] <tdonohue> hpottinger: that was the same question pbecker asked. There has not been a date set that is "last date for PRs" (yet)
[20:53] <bollini> we can have a 1-2 week testathon but we should indicate 1-2 days where we (committer or at least RT can assure hight involvement)
[20:54] <helix84> tdonohue: andrea said that we need to be able to provide concentrated support effort in a short time period, by being always present on IRC.
[20:54] <hpottinger> tdonohue, I think last time around, at your suggestion, we added such a date to the schedule for 3.0
[20:54] <tdonohue> mhwood: my only issue with a two day testathon is that we are normally asking repository managers (DCAT folks, etc) to help with testathon. In doing so, we really cannot tell them they have to do all their testing in 2 days.
[20:54] <mhwood> Last date for *feature* PRs is the feature freeze date. Last date for bugfix PRs is when the RT says "no more".
[20:55] <hpottinger> mhwood: is feature freeze really the same thing as PR freeze? I thought feature freeze was "last day to merge new code"
[20:55] <tdonohue> No.."Feature Freeze" = "Last date to MERGE 'feature' PRs", which is different from "Last date to submit feature PRs"
[20:56] <tdonohue> hpottinger: you are correct, I suggested having a "Last date to submit feature PRs" (even if it's a "soft deadline" / recommendation). But, I'm letting the Release Team decide whether you all think that's worth doing
[20:56] <hpottinger> back in the days of Subversion, that was pretty much the same thing... but with Git, we have split code changes and code merges
[20:56] <mhwood> Isn't the period between Feature Freeze and RC1 the final feature merging period?
[20:57] <hpottinger> tdonohue, I thought it was a good idea for 3.0, I still think it's a good idea for 4.0
[20:57] <pbecker> above we said that the deadline for a pr depends on the pr as the size of a pr is crucial to the time needed for the review.
[20:57] <tdonohue> Yes, worth noting that even with 3.0, we had several folks (committers even) who assumed "Feature Freeze" wrongly meant "last day to submit their PR". That caused big delays in the 3.0 release, as we suddenly received a lot of massive PRs at the last moment which were "incompatible" with one another. It caused everything to be unstable for a period and pushed back all our initial planned deadlines
[20:58] <tdonohue> (Others on the 3.0 team can verify that...maybe I'm exaggerating slightly...but I recall a large number of last minute PRs right at the Feature Freeze, which caused RC1 to be delayed by several weeks)
[20:59] <helix84> yes, it was probably the biggest reason for delay
[20:59] <tdonohue> So, my point with 4.0 is that, if we let "Feature Freeze" = "Last date to submit a PR", it may not be very reasonable to expect RC1 to be ready in just 11 days
[20:59] <hpottinger> It more of us seeing an oncoming wave of PRs and less of an actual manifestation of that wave, declaring the due date I think helped
[20:59] <robint> Always better to set tough deadlines and then relax them rather than plan for last minut contributions
[21:00] <tdonohue> +1 robint
[21:00] <hpottinger> +1 robint
[21:01] <hpottinger> it will also help very much if we have people merging their own code, or coordinating the review and merge amongst a few committers, so we don't have one big merge event like we did last year (which was fun, I'll give you that)
[21:02] <mhwood> I've been suggesting that feature deadlines be negotiated individually so the review work can be scheduled.
[21:02] <tdonohue> So, if it were me, I'd want to play things a little "safe" with 4.0. Either set a "rough" / "soft" deadline of Oct 7 or 13 for "Last day to submit PRs" (and make some exceptions for specific folks if needed). OR, increase the time between Feature Freeze and RC1 to allow for "unexpected" last-minute PRs. I lean towards the former...but I'll let the Release Team decide what you want to try.
[21:03] * helix84 remembers the fun, and remembers we were then fixing bugs in 3.1 that shouldn't have been in 3.0
[21:04] <tdonohue> mhwood: I think that's a great idea. But, It assumes that the Release Team knows about everything that will come in as a PR...and I've found that there's usually always a few surprises (and it's best to try and avoid having those be "last minute surprises")
[21:05] <tdonohue> mhwood: So, it could be a combo of both. Have the RT try and negotiate feature deadlines individually...but also set a public deadline as a "just in case" scenario for things we may not know about yet
[21:05] <bollini> I'm not convinced
[21:06] <mhwood> The public deadline would be "for certain nothing will go into 4.0 after this date, but if your work is big we'd like to see it sooner."
[21:06] <bollini> we will give a deadline for PR and we can assure that we will review them
[21:06] <tdonohue> So, those are my recommendations. But I am going to step back now. I would like the RT to decide what you want to do. If you want to try it another way, feel free. I'll support you either way.
[21:06] <tdonohue> mhwood: yea, that's exactly what I meant.
[21:06] <bollini> it should be more a suggestion against a "prize"
[21:07] <bollini> if you send your PR before the deadline we assure that we will do an IRC meeting where all the PR will have 5 minutes of review
[21:07] <hpottinger> bollini what are you not convinced by?
[21:07] <mhwood> bollini: interesting.
[21:07] <helix84> honestly, RT, just already throw some dates out there officially, please, and everyone will have to respect them
[21:08] <hpottinger> I'm OK with the schedule as suggested by bollini, with the addition of a PR due date, and the one suggested by tdonohue sounds fine: Oct 7.
[21:09] <tdonohue> bollini: if you'd like to recommend we have a public PR IRC meeting, I'd support that.
[21:09] <bollini> tdonohue: yes, I want a public PR IRC meeting if we introduce a deadline for PR submission
[21:10] <hpottinger> our current PR review *is* public, yes? the first few minutes of the dev meeting
[21:11] <helix84> yes, we'll just need more time to do the reviews after the freeze
[21:11] <mhwood> This would be a *guarantee* that submissions by the deadline would be discussed in time for inclusion in 4.0.
[21:11] <hpottinger> oh, yeah, I think that's only fair
[21:12] <hpottinger> let's plan on that part of the dev meeting to "scale out" after the PR due date
[21:12] <robint> Got to go, cheers all
[21:12] * robint (522a6b02@gateway/web/freenode/ip.82.42.107.2) Quit (Quit: Page closed)
[21:13] <mhwood> Can we hash this out on -release and commit to producing a schedule by the end of Friday?
[21:13] <tdonohue> yea, either we "scale" out the PR review portion of the meeting, or we devote an entire meeting to PR reviews
[21:13] <tdonohue> essentially saying: "If you give us your PR by this date...we promise that you can hear our live 5-min feedback in an IRC meeting at this date/time".
[21:14] <tdonohue> though, maybe that's tough..depending on how many PRs we get ;)
[21:14] <hpottinger> tdonohue: I don't know if we can really expect all the committers to be able to coordinate another meeting time, I think we can afford to devote one or two dev meetings to this task, what does everyone else think?
[21:15] <mhwood> I assumed that it would be the dev meeting.
[21:15] <tdonohue> I'm fine with bringing this to -release , as long as the RT makes it a goal to final this week / early next. It'd be best to get a public announcement sent sometime next week to give folks time to prepare (especially developers)
[21:16] <mhwood> Is there anything else we need to discuss in realtime right now?
[21:16] <tdonohue> hpottinger: yea, I agree. Didn't mean it to be a *separate* meeting. I meant it to be a particular week's devel. meeting would be 100% devoted to PR reviews.
[21:16] <tdonohue> (and we'd do our best to get through as many as we could)
[21:17] <tdonohue> I don't have anything else to discuss in realtime right now. Finalizing 4.0 Schedule was our main topic for today. No other agenda items
[21:18] <mhwood> Are we enough in agreement that we can close on a schedule on -release?
[21:18] <bollini> I think so. Good time. Thanks to all I leave now.
[21:18] <helix84> tdonohue: what would be a good wiki page to describe the meanings of our Jira labels?
[21:19] * bollini (~chatzilla@host119-68-dynamic.11-87-r.retail.telecomitalia.it) has left #duraspace
[21:19] <richardrodgers> got to go - bye all
[21:19] * richardrodgers (~richardro@18.189.38.181) Quit (Quit: richardrodgers)
[21:19] <hpottinger> mhwood: I can respond to bollini's note on -release, but I'm in agreement with his schedule, with the addition of a PR due date
[21:19] <mhwood> I also must depart. I'll give close attention to -release until we can get a schedule out. 'bye!
[21:20] * mhwood (mwood@mhw.ulib.iupui.edu) has left #duraspace
[21:20] * kstamatis (5e42133c@gateway/web/freenode/ip.94.66.19.60) Quit (Quit: Page closed)
[21:20] <tdonohue> helix84: Since JIRA labels are likely something the Committers will mostly need to manage, perhaps create a new wiki page: "JIRA Usage" or "JIRA Tips" off of: https://wiki.duraspace.org/display/DSPACE/Committer+Guidelines ? That's the best place I can think of right now
[21:20] <kompewter> [ Committer Guidelines - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/Committer+Guidelines
[21:21] <helix84> tdonohue: we already have https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[21:21] <kompewter> [ JIRA Workflow Improvements - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/JIRA+Workflow+Improvements
[21:21] <helix84> tdonohue: which has been implemented, so it could be part of the "official" page, too
[21:22] <helix84> tdonohue: maybe I should just move that page
[21:22] <tdonohue> yep, true. that JIRA workflow could be part of an "official" page on how we use JIRA.
[21:22] <helix84> so should I move and edit it or create a new one and copy parts of the old one?
[21:24] <tdonohue> Either way is fine by me. I'm not sure that old proposal page really needs keeping around as-is. It's more important to document our existing JIRA workflow & what labels we encourage using, etc.
[21:24] <tdonohue> So, I'm OK with you just moving that page / renaming if it's easiest.
[21:29] * pbecker (5cce51d9@gateway/web/freenode/ip.92.206.81.217) has left #duraspace
[21:34] <helix84> I created a new one because I didn't want to delete the comments:
[21:34] <helix84> https://wiki.duraspace.org/display/DSPACE/JIRA+Usage
[21:34] <kompewter> [ JIRA Usage - DSpace - DuraSpace Wiki ] - https://wiki.duraspace.org/display/DSPACE/JIRA+Usage
[21:35] <helix84> Could you please correct the diagram? I don't want to struggle with WYSIWIG again.
[21:35] <helix84> for me it's never what I see is what I get
[21:37] <tdonohue> haha :) ok. will do. Thanks for getting it started
[21:38] <helix84> just fininshing some minor changes
[21:41] <tdonohue> let me know when you are done. I basically have to copy & paste the diagram over...not hard, just don't want to overwrite your work
[21:45] <helix84> i'm done
[21:45] * hpottinger (~hpottinge@mu-161244.dhcp.missouri.edu) Quit (Quit: Later, taterz!)
[21:45] <helix84> we may want to remove the "ready for test" and "ready for release" states - i don't think we're using them
[21:53] <tdonohue> ok, added the diagram.
[22:03] * tdonohue (~tdonohue@c-67-177-111-99.hsd1.il.comcast.net) Quit (Read error: Connection reset by peer)
[22:10] * helix84 (~a@ip4-95-82-147-170.cust.nbox.cz) has left #duraspace
These logs were automatically created by DuraLogBot on irc.freenode.net using the Java IRC LogBot.