Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. 4.3.0 Release is out

    1. Process reflections and improvements
    2. Release candidates?
    3. 4.4.0 Release manager?
  2. 4.4.0 focus
    1. Move projects into fcrepo-exts (see: F4 GitHub Organizations)
      1. Rename packages to "org.fcrepo.exts", or something else entirely
    2. Decouple those projects from the fcrepo4 pom.xml parent
    3. Plan on all extras projects starting independent versioning with 4.4.0
      1. Therefore, 4.4.0 will represent a common ground zero
    4. OSGi - demonstrate runtime configurability of F4?
    5. Servlet-API version? 3.01 -> 3.1.0
      1. Modeshape depends on 3.1.0
      2. This would imply a hard requirement on Tomcat 8 or Jetty 9.1 for deployment
      3. OSGi already requires 3.1.0 and Karaf 4 as a container
  3. Move to a four-digit version number scheme?
    1. Community comment: Re: Fedora 4 Semantic Versioning
  4. ...

  5. Current Priorities

    1. Performance
    2. Single subject
    3. fcr:metadata as a container
    4. Point-like objects
    5. Camel RDF serializer
    6. Migration-utils
      • Wait for Mike
    7. Bugs
  6. Tickets resolved this week:

  7. Tickets created this week:

Minutes

  1. 4.3.0 Release is out

    1. Process reflections and improvements
      1. There were a few last-minute pull requests – having a longer code freeze might be better.
      2. Or maybe we should have release candidate branches that get voted on?  This is the way that other projects work, e.g., Apache.
        1. Esme, Nick and Adam are all in favor of having release candidates
        2. Release candidates could be open for testing/voting for months, or just a few days
        3. Aaron: So we'd want to agree on process, how long to leave release candidates are open for testing and voting, etc. and update the release docs
    2. 4.4.0 Release manager?
      1. Yinlin volunteered
  2. 4.4.0 focus
    1. Timeframe is uncertain
    2. Move projects into fcrepo-exts (see: F4 GitHub Organizations)
      1. Rename packages to "org.fcrepo.exts", or something else entirely
        1. Adam: who is taking responsibility for the modules should decide what namespace is used
        2. Aaron: do we want to add "exts" to e.g., org.fcrepo.transform?
          1. No need to make a decision right now, but we will need to resolve these
    3. Decouple those projects from the fcrepo4 pom.xml parent
      1. Aaron: some can be decoupled (Camel, client, etc.)
        1. But transform, audit, and anything that interacts with the kernel will need to continue depending on fcrepo4
      2. Esme: So we should go through the projects and decide what can be decoupled and what needs to depend on fcrepo4
    4. Plan on all extras projects starting independent versioning with 4.4.0
      1. Aaron: For decoupled projects, there's no compelling reason to keep the versions in sync, but the audit/transform/etc. projects might be better to keep in sync
      2. Adam: I would hope we could decouple the version numbers, and as the API specification goes forward, we might be able to dissolve them and make them not Fedora-specific as much as possible
      3. Aaron: So we'd be separating the fcrepo4-api and fcrepo4-impl into separate projects
      4. Adam: Absolutely
      5. Aaron: And we could break out a number of utilities that aren't related to the Modeshape implementation
      6. Adam: They could go in the kernel-api (as long as they are related to the models and not any implementation)
    5. OSGi - demonstrate runtime configurability of F4?
      1. Aaron: There's been progress here, optimistic about this
    6. Servlet-API version? 3.01 -> 3.1.0
      1. OSGi is more strict about dependencies, so it would require 3.1.0, and Modeshape depends on 3.1.0 (we're downgrading to 3.0.1 in our Maven config)
      2. The downside is losing compatibility with older servlet containers like Tomcat 7 (Tomcat 6 is EOL at the end of 2016, so expect Tomcat 7 to be supported for quite some time)
      3. We may be able to just depend on whatever JAX-RS provides and not have this explicitly required
  3. Move to a four-digit version number scheme?
    1. Community comment: Re: Fedora 4 Semantic Versioning
      1. Since the "4" is fixed, our versioning system isn't really the same as the standard semantic versioning
      2. Having a four-digit version number could be more clear
      3. Adam: Not sure anyone's confused – backward compatibility may be an issue
      4. Aaron: We've been focused on moving forward, not maintain backwards compatibility
      5. Esme: Not a lot of production installations yet, so not much emphasis on version/API stability yet – but that will change as more people migrate
      6. Aaron: Move to 4.4.0 and new versioning schemes is probably a good time to move to a four-digit version numbering scheme
      7. Adam: Better to make any changes sooner rather than later
  4. Current Priorities
    1. FCREPO-1609: Adam: General interest in how fcrepo4 handles large RDF, not any real-world scenario
      1. Bethany: Is this related to the OutOfMemoryError issue?
      2. Esme: No, that's a real practical issue, this is more of a benchmarking task
    2. FCREPO-1474: Adam: Related to fcr:versions and fcr:metadata, I've done most of the sub-part related to fcr:metadata, but need some HTML fixes
      1. Expecting Benjamin Armintor to chime in here
    3. FCREPO-1590: Esme: Not sure we've really reach consensus, but this responds to a real use case, and shouldn't be too challenging to implement since we already have working containers
    4. FCREPO-1470: Adam: This is non-container RDF sources, as requested by Aaron Birkland and others.  There haven't been any developer resources dedicated to this, yet
      1. Related to having RDF that describes non-repository subjects
    5. FCREPO-1519: Esme: We had a call to talk about requirements, I'll revise those requirements and UCSD will take a stab at implementing it soon