Versions Compared

Old Version 7

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version 8

changes.mady.by.user Unknown User (escowles@ucsd.edu)

Saved on

Key

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

...

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

    Expand
    1. Performance
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1609
    2. Single subject
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1474
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1540
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1447
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1411
    3. fcr:metadata as a container
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1590
    4. Point-like objects
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1470
    5. Camel RDF serializer
      • Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyFCREPO-1519
    6. Migration-utils
      • Wait for Mike
    7. Bugs
      • Expand
        • Jira
          serverDuraSpace JIRA
          columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
          maximumIssues20
          jqlQueryfilter=13122
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5

  6. 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

  7. 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. 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