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

Using timezone: Eastern Standard Time
* jgpawletko leaves07:29
* dhlamb joins08:32
* awead joins08:46
* acoburn joins08:59
* whikloj joins09:30
* awoods joins09:35
* ajs6f joins09:41
* jmignault leaves09:52
* github-ff joins09:55
[fcrepo4] whikloj closed pull request #801: PUT/POST must fail if triples not persisted (master...FCREPO-1417) http://git.io/vkTVA
* github-ff leaves
* ksclarke joins
<acoburn>awoods: does this page tell you the "this is not an active repository"? https://travis-ci.org/fcrepo4/fcrepo4/10:04
<awoods>on a call
<ajs6f>acoburn: Can't you see that the man is on a call?!?!
<acoburn>ajs6f: that man is always on a call10:05
<ajs6f>acoburn: We're being oppressed by the man. Not the Man, merely the man.10:06
* jgpawletko joins10:11
* dwilcox joins10:21
* ajs6f1 joins10:45
* ajs6f leaves10:48
* ajs6f1 leaves10:49
* ajs6f joins10:52
* bseeger joins10:59
<ajs6f>https://wiki.duraspace.org/display/FF/2015-08-13+-+Fedora+Tech+Meeting11:00
I'm here.11:01
<whikloj>Me too
ruebot++11:02
NOOOOOO!!!!
dhlamb: ruebot is using his power for evil today11:03
<awoods>https://jira.duraspace.org/issues/?filter=1312111:15
<ruebot>https://jira.duraspace.org/issues/?filter=13121&jql=project%20%3D%20FCREPO%20AND%20status%20in%20%28Open%2C%20Received%29%20ORDER%20BY%20issuetype%20ASC%2C%20priority%20DESC%2C%20key%20ASC -- all the bugs listed first11:16
<awoods>https://jira.duraspace.org/issues/?filter=1312211:18
<ajs6f>NO NEW FEATURES EVER!11:24
<ruebot>using_jira++11:28
ajs6f++
<whikloj>awoods++11:30
<escowles>awoods: sorry, gotta run to another meeting...
<whikloj>ajs6f: the lingo is definitely not "the kids"11:32
<ajs6f>whikloj: The kids, with their jazz music and their reefer and flared trousers and whatnot...11:33
<whikloj>ajs6f++11:35
<ajs6f>awoods++
acoburn++11:36
<ruebot>this sound right for the action item?
"Action: Andrew Woods to restructure priorities and focuses in JIRA."
<ajs6f>"Action: Andrew Woods to restructure priorities and focuses in JIRA to represent the project vision [as awoods described it earlier in this call] and then get ajs6f a beer."11:37
<whikloj>acoburn: https://jira.duraspace.org/browse/FCREPO-156311:38
<ruebot>ajs6f++
<ajs6f>acoburn:whikloj: https://jira.duraspace.org/browse/FCREPO-1312 is more specific.11:39
<ruebot>did awoods just turn into lebron james?
<whikloj>ruebot: in that awoods loves Cleveland?11:43
<ruebot>whikloj: it was the, "not 5, not 6, not 7" statement11:44
<whikloj>ruebot: haha
<acoburn>awoods: we could start by changing the github orgs from fcrepo4 -> fcrepo11:45
<whikloj>Fedora: much better than before11:46
<ruebot>Fedora: much better than befora11:47
<whikloj>ruebot++11:49
<bseeger>their example included the words alpha and beta, which then would make sense that the qualifier is a lesser version.11:50
<ajs6f>https://en.wikipedia.org/wiki/G%C3%B6del_numbering
<whikloj>just change the product name to FedoraFour11:51
<ajs6f>whikloj++
Fourdora.
<ruebot>still sad we missed the opportunity for 4.0.4 release11:52
<whikloj>ruebot++
<ruebot>my vote: leave it as is.11:53
<ajs6f>ruebot: We didn't miss the opportunity. Not having a 4.0.4 available is _exactly_ what made sense.
<ruebot>ajs6f++
<dhlamb>got to go. getting sucked into another meeting :(11:59
<ruebot>notes are live12:02
<awoods>thanks, ruebot12:03
<ruebot>de nada awoods12:05
* acoburn leaves12:12
* bseeger leaves12:19
* dwilcox leaves12:25
* acoburn joins13:10
* ajs6f leaves
<acoburn>whikloj: awoods: for fcrepo-transform, wouldn't the groupId stay the same? (org.fcrepo)13:11
<whikloj>acoburn: that was my first reaction, but then I figured I'd ask incase it was not the (Java) norm or if we wanted to make a break.13:12
<awoods>acoburn: Sure... although it would be good to come up with some consistent approach for making that decision.
<acoburn>whikloj: the other extension module we have (fcrepo-audit) uses org.fcrepo13:13
awoods: I agree
<whikloj>acoburn: yes but that was before the grand-reshuffling was started
<awoods>acoburn: several projects are currently making their way to fcrepo4-exts...
acoburn: which keep "org.fcrepo"? which change? and why?13:14
<whikloj>awoods/acoburn: I have no problem leaving it as is (sort of a grandfather clause)
<acoburn>awoods: honestly, I have almost no opinion on the matter, other than to have a rule that we apply consistently
<awoods>whikloj/acoburn: Especially since Sonatype has let us know that we can restrict release privileges to subdomains (e.g. org.fcrepo.audit), maybe it is lower concern.13:15
<acoburn>awoods: I wouldn't want such granular use of groups (e.g. org.fcrepo.audit or org.fcrepo.transform)13:17
awoods: but I'm also OK with putting all "extension-like" modules in org.fcrepo.ext
<whikloj>awoods/acoburn: that's a fair point, it could be org.fcrepo.exts
^^++
<acoburn>awoods: e.g. fcrepo-mint seems to moving in that direction
<awoods>acoburn: meaning, you would not want to restrict release privileges on a per-project basis?13:18
<acoburn>awoods: actually, that's a good reason to have very granular groupIds
<awoods>acoburn: I am trying to interpret: "I wouldn't want such granular use of groups (e.g. org.fcrepo.audit or org.fcrepo.transform)"13:19
<acoburn>awoods: what I'd like to clarify is "why" have such granular groupIds13:20
awoods: sonatype privs are a good rationale for that
awoods: simple project organization in maven-central seems like not such a good reason
<awoods>acoburn: Sonatype is the only reason I know of
<acoburn>awoods: exactly13:21
awoods: then having granular module-based groupIds makes sense to me
<awoods>acoburn: Using "org.fcrepo.exts" somewhat breaks that model13:22
<acoburn>awoods: yes it does
awoods: then for fcrepo-1670, it seems like the best option is org.fcrepo.transform correct?13:23
<whikloj>awoods/acoburn: okay so org.fcrepo.transform
<awoods>acoburn/whikloj: ++
<whikloj>acoburn++
<awoods>acoburn/whikloj: The question becomes, for projects in fcrepo4-exts, do we require the "org.fcrepo.*" package prefix?13:24
<whikloj>awoods/acoburn: I'd say no
<awoods>acoburn/whikloj: as it stands now, all committers do or can have Sonatype release privileges on "org.fcrepo"
<whikloj>awoods/acoburn: Right but stuff in fcrepo4-exts could be maintained by non-committers.13:25
<acoburn>awoods: I think it depends on who will be contributing/maintaining that project
<whikloj>acoburn++
<acoburn>awoods/whikloj: I also don't see that it is necessary for fcrepo4-exts projects to use the org.fcrepo namespace13:26
they may not all be JVM projects, after all
<whikloj>acoburn++
<awoods>acoburn/whikloj: agreed... what I wonder is: what does it mean for a project to be in fcrepo4-exts? and if a project is there, and the owner goes away, I imagine we still want to be able to release it.13:27
* awead_ joins
<acoburn>awoods/whikloj: at that point, there are a few decisions that would have to be made
(1) will it be maintained13:28
(2) will there be further releases
(3) does it still belong in -exts
<whikloj>I agree on point 1 & 2, if they are both no, then I think 3 is answered
<awoods>acoburn: for the sake of argument, let's assume all three answers are "yes".13:29
...for a given project
<acoburn>awoods: then there would need to be a new maintainer found (or group of maintainers)
awoods: but, stepping back for a minute, why would there be a project in -exts that has only a single maintainer?13:30
awoods: I'd think that one criterion of being in -exts is that it has more community support
<whikloj>acoburn++
<acoburn>awoods: so if a single maintainer leaves, the project isn't left in limbo
<awoods>acoburn: projects in -exts need to have at least one owner who performs releases.
acoburn/whikloj: if there are more than one owners, that is great.13:31
<acoburn>awoods: I would think that a project with only one owner could safely live in -labs
* awead leaves
<awoods>acoburn/whikloj: but the Fedora committers are not obligated to maintain/release -exts projects.
<whikloj>awoods/acoburn: agreed13:32
<acoburn>awoods/whikloj: agreed
<awoods>acoburn/whikloj: The fact is, someone(s) need to formally take responsibility for each exts project.
<acoburn>awoods++13:33
<whikloj>awoods++
<awoods>acoburn/whikloj: and if that person(s) goes away, then we face the three questions.
<whikloj>acoburn/awoods: I think the big question is if the lead leaves, can (and will) the community pick the project? If no, then fcrepo4-archive
<acoburn>awoods/whikloj: or -labs13:34
<awoods>whikloj: sure
acoburn: sure
<whikloj>acoburn/awoods: and by pickup I mean someone has to take formal responsibility
<awoods>acoburn/whikloj: I am coming at this from a release/Sonatype perspective...
<whikloj>acoburn: I don't think going from -exts to -labs makes sense. It implies it might come up again.
<awoods>acoburn/whikloj: Currently, we have ownership of the "org.fcrepo" package namespace with Sonatype13:35
<acoburn>whikloj: yes, very likely it should go to -archive
<awoods>acoburn/whikloj: We can grant and revoke release privileges on that namespace
<acoburn>awoods: re sonatype, everything in core clearly needs to go there13:36
<awoods>acoburn/whikloj: There are Sonatype hoops to jump through to create ownership of other namespaces.
<whikloj>awoods: so your concern is if we don't control the namespace, and the lead leaves how does it get released?
<awoods>whikloj: exactly
<whikloj>awoods: I would use acoburn's suggestion of at least 2 owners at all times13:37
<acoburn>awoods: in that case, I would think there might need to be a namespace migration
<whikloj>acoburn: I thought of that, and it could work but would be annoying. Still it is an option.
<acoburn>whikloj: very annoying indeed13:38
<awoods>acoburn/whikloj: which makes at least wonder if a requirement for being in fcrepo4-exts for the outset is being under "org.fcrepo"
acoburn/whikloj: which makes me at least wonder if a requirement for being in fcrepo4-exts from the outset is being under "org.fcrepo"13:39
<acoburn>awoods/whikloj: that certainly would make things easier
<whikloj>awoods/acoburn: I see your concerns, but I think those projects going into -exts are generally already community supported. The real test will come from outside (like the API extension)13:40
<acoburn>whikloj: that will be an interesting test of this13:41
whikloj: but if this is all OSGi-based, those extensions can, in reality, live anywhere
whikloj: it will be mostly a question of whether any of those are picked up to live in -exts13:42
<whikloj>acoburn: and I think that gets to the heart of the matter. If these are extensions then they are not "required" for Fedora and if the maintainer drops them, it would be unfortunate but not the end of the world.
<acoburn>whikloj/awoods: for instance, org.apache.camel keeps adding new extensions, and one requirement is that the new extension have the o.a.c namespace13:43
whikloj/awoods: and there are some camel extensions that aren't part of the central camel release (e.g. activemq-camel)
whikloj/awoods: and that has its own package namespace and lives over in the apache/activemq repository13:44
whikloj/awoods: but at runtime, none of that matters
<awoods>acoburn: sure, this is all policy/release discussion.13:45
<acoburn>and another camel extension is fcrepo-camel, which doesn't have the o.a.c namespace
<awoods>acoburn: Where does that land you?13:46
<acoburn>awoods: right, but the fedora committers/contributors/maintainers should't be responsible for every extension module anyone happens to write
<awoods>acoburn: Absolutely not. agreed13:47
acoburn: But we should be able to if needed, no?
<acoburn>awoods: I think anything in -exts implies a certain level of commitment on the part of the fedora team
awoods: and anything in -exts also implies that we have control over releases13:48
<whikloj>awoods: no
<acoburn>awoods: everything else is out of scope13:49
awoods: that is, out of the scope of responsibility of the fedora team
<whikloj>acoburn: what do you mean "we have control over releases", then we need Sonatype permissions no?
<acoburn>whikloj: I guess that's what I mean13:50
<awoods>acoburn: does that imply a requirement for the "org.fcrepo" package namespace?13:51
<acoburn>awoods: it certainly seems to
<whikloj>awoods/acoburn: See I feel that if it is an extension, and it is so limited in support that no one will take responsibility for it. Then it probably should die.
* dwilcox joins13:52
<whikloj>awoods/acoburn: it will die slowly from lack of care anyways.
<awoods>acoburn/whikloj: I need to dash... please continue the conversation with an eye towards a policy.13:54
afk
<whikloj>acoburn: it sounds as if we are back to everything in -exts is under org.fcrepo? The reason seems to be to ensure those extensions can continue if those people that created them stop.13:55
<acoburn>whikloj: that is, under org.fcrepo.<something>13:56
whikloj: that way we can be granular about sonatype permissions, if necessary
<whikloj>acoburn: for everything that we house in fcrepo4-exts, things out on the interweb are free to do as they please.13:57
<acoburn>whikloj: where <something> relates to the particular project (transform, audit, camel, etc)
whikloj: exactly
<whikloj>acoburn: Are we taking responsibility for these projects then?
acoburn: Just thinking about workload.
* awead_ joins13:58
<acoburn>whikloj: given that they are part of published releases, I say yes
<whikloj>acoburn: what about if we stop with tying releases together?
<acoburn>whikloj: that shouldn't be an issue13:59
<whikloj>acoburn: Right I'm just noticing that fcrepo4-core is getting smaller, but Fedora is getting bigger :)
<acoburn>whikloj: what I'm thinking is this: we release fcrepo-webapp-plus
* awead leaves
<acoburn>whikloj: and that depends on fcrepo-audit
whikloj: and we also distribute the camel integration packages, which depend on fcrepo-camel14:00
whikloj: and yes, as long as core gets smaller, we're probably doing the right thing
<whikloj>acoburn: okay so what is the process to get into fcrepo-exts?14:01
<acoburn>whikloj: it is ill-defined
whikloj: at one of the tech calls we discussed a list of modules, but that's it14:02
<whikloj>acoburn++
<acoburn>whikloj: someone needs to write up a policy
whikloj: and part of that policy should be some statement about who will be supporting it14:03
whikloj: for example, the fcrepo-karaf module is in labs right now. I think it's really useful, but I'm the only one working on it
whikloj: and I've been telling awoods that, therefore, it's not ready for -exts14:04
<whikloj>acoburn: right. So maybe some sort of nomination process and a mailing list poll of supporters/users.
<acoburn>whikloj: once fcrepo core can run in OSGi, it will probably become more relevant
<whikloj>acoburn++
<acoburn>whikloj: I think it's more about people just stepping up and doing the work14:05
<whikloj>acoburn: it is but how do you get support so it's not all on your back. Do we pull from the community, and how.14:06
<acoburn>whikloj: yes, it needs to come from the community14:07
<whikloj>acoburn: so the question is how much community support is enough to get into fcrepo4-exts. Do we need people need to provide developer time?14:11
<acoburn>whikloj: that is definitely the question. as for asking for specific dev time commitments, that might be too high a bar14:13
whikloj: if a project isn't being maintained, it should simply to to -archive
whikloj: and with jenkins, etc, it will be obvious which projects are not being maintained
<whikloj>acoburn++14:14
<acoburn>whikloj: however…. if our separation of API and implementation really works, then some ext components shouldn't need too much attention14:15
whikloj: I've barely touched fcrepo-camel in 6 mos
<whikloj>acoburn: right, this is just to keep awoods from worrying later ;)
* dhlamb leaves14:39
* github-ff joins15:19
[fcrepo-camel] acoburn opened pull request #87: fix error in readme (master...fix-readme) http://git.io/v36oS
* github-ff leaves
* github-ff joins15:22
[fcrepo-camel] awoods pushed 2 new commits to master: http://git.io/v366w
fcrepo-camel/master 93bcd35 Aaron Coburn: fix error in readme
fcrepo-camel/master 262310d Andrew Woods: Merge pull request #87 from acoburn/fix-readme...
* github-ff leaves
* travis-ci joins15:26
fcrepo4-exts/fcrepo-camel#208 (master - 262310d : Andrew Woods): The build passed.
Change view : https://github.com/fcrepo4-exts/fcrepo-camel/compare/9a40f90d4e8c...262310defed7
Build details : https://travis-ci.org/fcrepo4-exts/fcrepo-camel/builds/75493765
* travis-ci leaves
* ajs6f joins15:33
* dwilcox leaves
* dwilcox joins15:35
* dwilcox leaves15:37
* dwilcox joins
* dwilcox leaves15:42
* acoburn leaves15:48
<ajs6f>Even today, almost than twenty years after his last regular battle, Rokusaburo Michiba remains the greatest Iron Chef ever to compete in Kitchen Stadium. Have a good evening, all.16:41
* ajs6f leaves
* whikloj leaves17:05
* jgpawletko leaves17:30
* jgpawletko joins17:52
* jgpawletko leaves
* ksclarke leaves18:14
* ksclarke joins18:38
* the_mgt_ joins19:40
* the_mgt leaves19:43
* dwilcox joins19:48
* dwilcox leaves20:24
* ksclarke leaves21:09
* ksclarke joins
* awead leaves22:40
* awead joins22:44
* awead leaves23:53
* awead joins00:04
* ksclarke leaves00:28
* awead leaves00:43

Generated by Sualtam