Log of the #fcrepo channel on chat.freenode.net

Using timezone: Eastern Standard Time
* dchandekstark joins02:07
* dchandekstark leaves02:11
* dchandekstark joins04:08
* dchandekstark leaves04:13
* dchandekstark joins07:10
* dchandekstark leaves07:15
* bseeger joins08:40
* arebenji joins08:48
* dchandekstark joins08:50
* dchandekstark leaves08:54
* mikeAtUVa joins09:14
* peichman joins09:17
* acoburn joins
* ajs6f joins09:25
* dchandekstark joins10:09
* ajs6f leaves10:17
<awoods>dchandekstark: would you like to add anything to today's agenda: https://wiki.duraspace.org/display/FF/2016-07-14+-+Fedora+Tech+Meeting ?10:21
<dchandekstark>awoods: i added myself to the attendees :)10:23
<awoods>dchandekstark: that's a start10:24
<dchandekstark>awoods: I'm just going to be there and see how it goes, since this is my first time10:25
want to see how y'all operate
<awoods>dchandekstark: you should enjoy that
<ruebot>dchandekstark++10:31
dchandekstark: soon you'll get the gold star, and start taking notes! :-)
* dchandekstark remove name from list :)10:32
* github-ff joins10:42
[fcrepo-module-auth-rbacl] peichman-umd opened pull request #33: Remove auto-registration of the AccessRolesResources component. (master...FCREPO-1853) https://git.io/vKRCY
* github-ff leaves
* github-ff joins10:43
[fcrepo-module-auth-xacml] peichman-umd opened pull request #52: Configure XACML to use fcr:accessroles (master...FCREPO-1853) https://git.io/vKRCC
* github-ff leaves
* github-ff joins
[fcrepo-module-auth-webac] peichman-umd opened pull request #69: Integration test for removing fcr:accessroles (master...FCREPO-1853) https://git.io/vKRCW
* github-ff leaves
* dchandekstark leaves10:45
* dchandekstark joins10:51
* duke_repo joins10:56
* ajs6f joins10:57
* ajs6f is here
* dchandekstark is here10:58
<ruebot>is anybody talking, or is it just silence?10:59
<ajs6f>You're either part of the solution or part of the problem.
<ruebot>ah, awoods is there now.11:00
<bseeger>*is here*
<ruebot>TUTTLE!!!
<acoburn>*is here*
* kat3_drx joins11:01
<awoods>https://wiki.duraspace.org/display/FF/2016-07-14+-+Fedora+Tech+Meeting11:02
<ajs6f>Is anyone else _not_ on the line?
acoburn++\11:03
<ruebot>acoburn++
* esm_ joins
* jt112 joins11:04
<ajs6f>That's basically Fedora 4's motto: "Hopefully, we can pull it all together."11:05
<dchandekstark>what does that mean: "absence of a spec"?11:06
* ajwagner just joined
<ajs6f>dchadekstark: A specification, such as is now being constructed, which explains how Fedora is _supposed_ to behave.
<ruebot>dchandekstark: the API Specification efforts; ...oh, ajs6f beat me.
<ajs6f>dchandekstark: There is no such specification right now.11:07
dchandekstark: So it is possible that you might thikn Fedora should do one thing and I think it should do another, and it's not clear to the team what to do.
dchandekstark: And it does happen.
<ruebot>ajs6f++
<ajs6f>Fedora resources are supposed to be durable, after all.11:08
acoburn++
<peichman>acoburn++11:09
<ajs6f>What does that phrase mean, "production ready"?11:10
I've never used that phrase.
* dwilcox joins11:14
<jt112>Is there an ongoing and active effort to write a spec?
<ruebot>jt112: yep!11:15
<ajs6f>I just stabbed myself with a constructive point.
<jt112>@ruebot Where might I find information about that effort?
<ruebot>jt112: https://wiki.duraspace.org/display/FEDORAAPI/Fedora+Specification
<ajs6f>jt112: Hell, yes: https://wiki.duraspace.org/display/FEDORAAPI
What I say is truthy.
Change management is definitely part of the spec process.11:20
<dchandekstark>ajs6f++11:21
<ajs6f>Oh, I'm just making stuff up, really. Sounds plausible, tho', eh?11:22
<ruebot>jt112: it's worth noting too, some of the specification efforts are a bit more in a formalized state here: https://github.com/fcrepo & http://fedora.info/spec/2016/05/20/resource-versioning
<dchandekstark>TCK?
<ajs6f>Technology compatibility kit.
<ruebot>dchandekstark: test compatability ..
ajs6f++
<jt112>ruebot thanks
<ajs6f>Java lingo for a test suite that mechanically checks an implementation of the spec to clear that it really does do what the standard says it should.11:23
I'm muted, so that's not me.11:25
acoburn++
If you're talking, please don't mute.11:27
If you are muted, please talk more loudly.
* esm_ chuckles11:28
<ajs6f>I could hear the laugh in your voice, awoods.
Echo time is like bullet time but not as cool.11:31
I think _you_ are echoing, awoods11:32
I think we should use UUIDs, a fresh one for each release.
<ruebot>yeah. we need to resolve the version numbering.11:33
<esm_>+1
<ruebot>we're looking more and more silly with it IMO.
is that something that just needs to be resolved at the fedora leaders or steering level?11:34
<ajs6f>ruebot: I think we (the tech folks) need to bring forward a coherent and sensible proposal.
* dwilcox leaves11:35
<acoburn>why not do both at the same time?
<esm_>A little behind on the modeshape 4 -> 5 backend transition. Does Modeshape itself not provide reliable migration tools on the backend?11:36
<peichman>at UMD for now we are still interested in Modeshape 4, for the time being at least11:38
<ajs6f>peichman: Are you saying that you are specifically interested in 4 for its own sake?11:40
* dwilcox joins11:42
<ruebot>ajs6f++
acoburn++
<peichman>ajs6f: not for its own sake, but for scheduling purposes for our production release
<ajs6f>peichman: So you would be cool with two releases, maybe even prefer them?11:43
<ajwagner>simultaneous++
<peichman>we have some internal pressures to get a production fcrepo up and running, and we do not have time to do a migration to Mode5 immediately
<ajs6f>Googd questions.
<esm_>E.g. maintaining backports on a 4.6 branch?11:44
<ajs6f>Right. It's the same cost problems as maintain LTS versions.
* esm_ nods
<peichman>another way of putting it: UMD is interested in the features in 4.6 more than the Mode5 migration right now
ajs6f: two releases would work for us, since we could do a 4.5.1->4.6->4.7 migration path11:45
<ajs6f>peichman: But one release would not be so good, because it forces to buy the new features with a MODE upgrade?11:46
<peichman>ajs6f: yes
<ajwagner>4.6 as final modeshape 4 release, simultaneously released with 4.7 as modeshape 5
<esm_>So two releases has some implications with resources and maintaining a 4.6 branch. Not releasing 4.7 implies that the modeshape 5 branch must continue to track master.
<ruebot>ok. sorry about that.11:47
<ajs6f>esm_++
<jt112>thanks11:49
* duke_repo leaves
* bseeger leaves11:54
* bseeger joins
* dchandekstark leaves11:55
<ajs6f>Thunderous applause.11:56
<esm_>ajs6f: yes behind the muted phones
<ajs6f>That's why this is a good pattern.11:57
* dchandekstark joins11:58
<ajs6f>Okay, "We release 4.6."
* jt112 leaves12:00
<ajs6f>AMBIGUITY...12:01
Closing phases. That's what this project is all about.12:03
bi bi
* kat3_drx leaves
<ajs6f>acoburn does minutes in between one blink of your eye and the next.12:04
<acoburn>awoods: notes are ready
<awoods>thanks, acoburn
* dchandekstark leaves12:05
<esm_>great notes! thanks acoburn12:06
* dwilcox leaves12:07
* bseeger leaves12:21
* esm_ leaves12:30
* peichman leaves12:49
* bseeger joins13:01
* kat3_drx joins
* dchandekstark joins13:03
* dchandekstark leaves13:08
* dchandekstark joins13:09
* dchandekstark leaves13:14
* kat3_drx leaves
* jjtuttle_ joins13:17
* jjtuttle_ leaves13:25
* jjtuttle joins13:28
* bseeger leaves13:59
* dwilcox joins14:20
* dwilcox leaves14:25
* dwilcox joins
* kat3_drx joins14:29
* dchandekstark joins14:32
* kat3_drx leaves
* kat3_drx joins14:49
* kat3_drx leaves14:53
<ajs6f>awoods:ruebot: What is the (proposed) schedule for sprints for the Im/Ex feature? Or is it up somewhere yet?14:59
<awoods>ajs6f: that will be one of the topic of the first meeting.15:00
ajs6f: the first meeting is 7/22 @3pm
<ajs6f>awoods: Cool, thnx15:03
* acoburn leaves15:04
<ajs6f>mikeAtUVa: ^^^
<awoods>ajs6f/mikeAtUVa: https://wiki.duraspace.org/display/FF/2016-07-22+-+Import+-+Export+Planning+Meeting
* dwilcox leaves15:16
* ajs6f leaves15:25
* peichman joins15:34
* mikeAtUVa leaves15:35
<awoods>afk15:38
* jrgriffiniii joins16:05
* arebenji leaves16:12
* peichman leaves17:01
* jrgriffiniii leaves17:11
* dwilcox joins17:45
* dwilcox leaves17:46
* dwilcox joins17:49
* dwilcox leaves17:56
* dchandekstark leaves17:57
* dwilcox joins17:58
* dchandekstark joins18:00
* dchandekstark leaves18:04
* kat3_drx joins
* jjtuttle leaves18:06
* jjtuttle joins18:08
* jjtuttle leaves18:13
* jjtuttle joins18:14
* dwilcox leaves18:22
* jrgriffiniii joins18:23
* dwilcox joins18:24
* kat3_drx leaves18:27
* kat3_drx joins
* kat3_drx leaves18:28
* dchandekstark joins18:32
* dchandekstark leaves18:37
* dwilcox leaves18:49
* dwilcox joins18:54
* dwilcox leaves
* dwilcox joins19:13
* dwilcox leaves19:17
* dwilcox joins19:26
* dwilcox leaves20:02
* dchandekstark joins21:28
* mikeAtUVa joins22:31
* mikeAtUVa leaves22:36
* github-ff joins23:14
[fcrepo-webapp-plus] awoods opened pull request #39: Remove auto-registration of the AccessRolesResources component. (master...fcrepo-1853) https://git.io/vK0pX
* github-ff leaves
* github-ff joins23:35
[fcrepo-camel-toolbox] awoods pushed 1 new commit to master: https://git.io/vK0jL
fcrepo-camel-toolbox/master b6faa07 bseeger: Fixes the fcrepo-serialization unit tests. (#97)...
* github-ff leaves
* dchandekstark leaves23:36
* dchandekstark joins23:43
* travis-ci joins23:51
fcrepo4-exts/fcrepo-camel-toolbox#252 (master - b6faa07 : bseeger): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel-toolbox/compare/38dfae3b3e59...b6faa07eafd7
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel-toolbox/builds/144905383
* travis-ci leaves

Generated by Sualtam