Page tree
Skip to end of metadata
Go to start of metadata

Time/Place

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

Attendees

  1. Danny Bernstein
  2. Andrew Woods
  3. Aaron Birkland 
  4. Bethany Seeger 
  5. Ben Pennell 
  6. Jared Whiklo 
  7. Peter Eichman
  8. David Wilcox

Agenda

  1. Announcements

    1. News: Lyrasis and DuraSpace Announce Intent to Merge
  2. 5.0.2:

    1. Release manager: Yinlin Chen

    2. Date:? 

  3. Ecosystem tools

    1. fcrepo-camel and fcrepo-camel-toolbox toolbox release
    2. fcrepo4-vagrant 
  4. Follow-up on https://github.com/fcrepo/Fedora-API-Test-Suite/issues/319
  5. Follow-up [REINDEXING SERVICE] Question about how it works
  6. Next steps for import/export/4→5 migration
  7. 5.1.0
    1. Ready for review
      1. FCREPO-1889 - Getting issue details... STATUS
      2. "Check if metadata is available in commons.js" : https://github.com/fcrepo4/fcrepo4/pull/1499
    2. Issues that are ready to be worked:
      1. FCREPO-2937 - Getting issue details... STATUS
      2. FCREPO-2936 - Getting issue details... STATUS
      3. FCREPO-2935 - Getting issue details... STATUS
      4. FCREPO-2976 - Getting issue details... STATUS
  8. <your issue here>
  9. Please squash a bug!

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  10. Tickets resolved this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

  11. Tickets created this week:

     Click here to expand...

    Key Summary T Created Updated Due Assignee Reporter P Status Resolution
    Loading...
    Refresh

Minutes

  1. Lyrasis and Duraspace are moving forward with an intent to merge process. There is some due diligence to be completed first. The merger in worst case will have no impact on the Fedora project, but in the best case Lyrasis has expressed an interest in investing resources in the Fedora project. There are opportunities for feedback if you or your organization have any available in the FAQ of the news release.
  2. Travis-ci has been purchased by Idera (https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc), should not have an impact but we might want to consider reviewing other options. (ie. Circle-ci)
  3. Yinlin has volunteered to be the manager for the 5.0.2 bug fix release. Still waiting on work for the c3p0 replacement. Possibly announce a release next Monday. No movement on the c3p0 for a new release, perhaps we should move to apache-dbcp for a more robust product.
    Missing the jackson-bind fix on the master branch, it is on the 5.0-maintenance branch. Need PRs on the 4.7-maintenance and master branch.
    A pending PR (https://github.com/fcrepo4/fcrepo4/pull/1399) which updates a variety of dependencies should have a CLA, we have not heard from the author but as this is just updating version numbers then we can take this as a one-time occurence. We would need to indicate in the CLA table.
  4. For a 4.7.6 release we also update the modeshape version in 4.7 to match 5 which includes the S3 fixes.
    A 4.7.6 release should occur ASAP and have more robust updates.
  5. Fcrepo-camel and camel-toolbox seem they are ready to go. Peter was able to drop in these two products in their test environment and it worked mostly.
    fcrepo-camel or camel-toobox has a reference to the 4.7 pom file as parent. Updating this to anything later than 4.7 makes Karaf un-happy. It throws an Invocation target exception when PAX exam was trying to launch Karaf. Perhaps let Karaf fail and work backwards.
    Would also like to make the fcrepo-camel-toolbox support 4.7 messages.
    Will we have a maintenance branch of the fcrepo-camel-toolbox to support the 4.7 messaging?
    We have tagged versions of fcrepo-camel that work with 4.7.x but all development will be working with 5.0.x+
    Fcrepo-camel and fcrepo-camel-toolbox have security updates that need to be fixed.
  6. API-tests for number of messages expected. We can switch == to >= and then look at a way for the user to specify an expected number of messages.

Actions



  • No labels