Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Please squash a bug!

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13122
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

  2. Tickets resolved this week:

    Expand

    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13111
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

  3. Tickets created this week:

    Expand
    Jira
    serverDuraSpace JIRA
    columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
    maximumIssues20
    jqlQueryfilter=13029
    serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

1) Maven BOMs

 

acoburn: Are we actually using our own BOMs? If not, maybe we should stop building them. Embrace or abort?

awoods: BOMs are for defining collections of dependencies that will work together. Not clear that BOMs really buys us anything that we aren't getting from dependencyManagement sections in POMs.

barmintor: No opinion.

awoods: If we get rid of them and everything works, then they weren't buying us much. But then maybe BOMs are cool, but we aren't using them to effect. Doesn't seem like there's much interest, so maybe we don't do anything for now.

acoburn: If no one really understands them well, maybe we should get rid of them.

awoods: No one is using Fedora in the way that would make a BOM complement useful.

acoburn: Even if we want to publish them, should they be in the core?

awoods: Maybe we should leave them alone until we have a specific reason to get rid of them.

 

acoburn: [complicated dependency example]

acoburn: When we have transitive dependencies, when should we call them out explicitly?

ajs6f: When the transitive dependency is interesting by itself.

acoburn: There are some dependencies on Apache Commons libraries that show the different approaches as to whether to call out a transitive dependency.

awoods: We have examples of both kinds of indirect dependencies (trivial and substantive). Does this screw up OSGi?

acoburn: Sort of. It's complicated. Don't worry your pretty little head about it.

awoods: What do people want to see out of this discussion?

acoburn: We should review our transitive dependencies.

acoburn: A lot of HTTP modules have direct dependencies on MODE. Once we sort that out, we should review their dependencies.

 

2) Commons RDF in fcrepo-kernel-api

 

acoburn: We are tight with Jena. We depend on its basic types to model RDF. fcrepo-kernel-api shouldn't be so closely tied to an RDF impl. Commons RDF could be used to abstract over the RDF facility for the API.

awoods: Making RDF engines pluggable.

acoburn: Commons RDF is very new, but moving forward. We should keep an eye peeled on this. Might make sense in the future.

barmintor votes in favor.

awoods: I suspect that people will keep an eye on this.

acoburn: That's it!

 

3) FCREPO-2074 - Deleting versioned resource does not delete all version information

 

awoods: Serious bug. [lengthy description of bug]

awoods: I have a PR. It's a priority.

barmintor: I'll review it.

 

4) Deprecate fcrepo-transform in favor of a Camel-based solution?

 

ajs6f: Let's get rid of fcrepo-transform and do transforms in Camel instead.

acoburn: Marmotta, in particular, is not OSGi-ready, so we might want to do some work to distribute OSGi-ready artifacts for that stuff.

awoods: Let's not build up our own Maven distributions. Let's go back to Marmotta and fix the problem there.

acoburn: That would be ideal, but Marmotta's release cycle is really long.

ajs6f/awoods: Let's start that conversation with Marmotta and se where it goes.

awoods: Need to check that we're covering all the use cases, but otherwise, cool.

 

5) Fedora 4.6.0 release plan

 

awoods: Stay with MODE4, to avoid having to finish migration tooling. Is FCREPO-2065 still a blocker?

barmintor: I'm still trying to look at that. Also, my office is really loud.

acoburn: awoods, you mean not basing this release on MODE5?

awoods: I am.

acoburn: That is disappointing.

Mopey silence ensues.

acoburn: Should we even bother to do a release?

awoods: We can do a release for those other tickets and improvements.

[discussion about versioning]

awoods: We can call this 4.6.0.

yinlin: What is the relationship between this release and Hydra?

awoods: There was speculation before OR about a quick release to help align Hydra's WebAC and Fedora's WebAC.

awoods: I don't understand what acoburn's problem is.

acoburn: How far away is Fedora/MODE5?

awoods: We have it. We need the migration tooling to go with.

acoburn: We want MODE5 at Amherst.

awoods: Bringing it back, do we have any blockers other than FCREPO-2065? Is FCREPO-2028 a blocker?

whikloj: There's a couple of integration tests that are tricky. Maven is beefing.

awoods: This issue will get done, but is it a blocker for release?

whikloj: We can do a point release later that moves the filesystem connector to where it needs to go.

General agreement that FCREPO-2028 is not a blocker.

awoods: Let's get this out soon. Just one blocker left, although FCREPO-1880 might be a blocker, too.

acoburn: Suspects that there are some serious problems with the calculations for child count.