Versions Compared

Key

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

...

  1. Islandora/F4 updates
    1. Good work happening here
    2. Nick: Should the Islandora use cases get translated into Fedora use cases?
    3. Andrew: Yes, if they are Fedora-appropriate.  Feel free to create a section to group them together.
    4. Danny: Ingest process using Camel: Islandora-specific right now, but should be generalizable.  Aaron added some great transaction support that will be useful for compound object building.  Will be useful both for bulk ingest and upgration.
  2. Upgration tooling updates
    1. Mike not on the call, but sent his status via email.
    2. Andrew: There is a design page (Fedora 3 to 4 Data Migration) – please give feedback on the design and how useful the functionality would be for you.
    3. Danny: I will email him because there is definite overlap with the Islandora ingest work.
    4. Esme: Could be a good topic for a lightning talk at Code4Lib next week – people have heard about Fedora 4 for a while, so letting them know about upgrade work could be good to get people interested in helping out.
    5. Andrew: And that could lead to a breakout too.
  3. 4.1.0 Release
    1. Andrew: Release just went outstarted, finishing up docs.
    2. Not a huge milestone, but lots of work since 4.0 last fall.
    3. This release is 4.1.0 instead of 4.0.1 because of breaking config changes, RDF vocabulary updates.
    4. Several projects (message-consumer and auth modules) had javadoc errors so they didn't get released to Maven central.
      1. Not a big deal because message-consumer can be downloaded separately, and the auth modules are embedded in the auth WAR build.  But we should make sure that javadoc errors are handled before release (ideally in Jenkins).
  4. Minor version support
    1. Aaron asked whether we would create bugfix updates for 4.0.x after 4.1.0 is released.
    2. Esme: Seems a lot like 3.x support, etc.: It would be nice, but may not be practical due to limited resources.
    3. Ben: Steering group was committed to security updates at least, so this is probably a question for the Steering group.  It may depend on whether it's a security issue, or serious enough that the release is pulled.  It would be good to have a policy about this.
    4. Andrew: So there should be policies for both security support and bugfix support.  The community places more value on core feature set than rapid feature development, so that would argue in favor of supporting a few older versions.
    5. Aaron: Many people are running much older versions, and might appreciate support for bugfixes.
    6. Esme: I'm not sure what the interest in upgrading older versions, even for security updates.
    7. Doron: Probably makes sense to focus efforts on 3.8, not older versions.
    8. Esme: Keeping number of 4.x minor releases down will make this issue less significant, as will getting developer resources to maintain older versions.
  5. Review of JIRA tickets
    1. Many issues are related to Sonar reports.
    2. FCREPO-1305: needs to be reviewed – Adam not available today – any volunteers?
      1. Esmé and/or Aaron can look at it later today.
    3. FCREPO-1246: important issue 
      1. Esme: definitely bad to have backups created and then not be restored – failing to create the backup would be much better
    4. FCREPO-1308: Aaron will review

    5. FCREPO-1290: Yinlin almost done
    6. FCREPO-1302: Want to work on this locally and identify bottleneck
    7. Grindr tickets
    Google Summer of Code, ideas
    1. should probably be pushed down, but Kevin is working on these
    2. Auth docs and issue with PATCH being allowed by non-authorized user (could be issue with Modeshape)
    3. FCREPO-1251: Ben: May be combination of .DS_Store and path with space.
      1. Esme: We had issues with spaces in paths before, could be a new instance of that problem.
    4. Should talk about the process and make sure the review is useful.