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 - out
  3. Aaron Birkland 
  4. Bethany Seeger 
  5. Ben Pennell 
  6. Jared Whiklo 
  7. James Silas Creel (star)
  8. Yinlin Chen
  9. Peter Eichman
  10. David Wilcox
  11. Jon Roby

Agenda

  1. Announcements

  2. 5.0.2:

    1. Release manager: Yinlin Chen

    2. Date: February 6th

    3. Release Testing - 5.0.2

  3. Ecosystem release/development policy review

  4. Status on current tools:
    1. fcrepo-camel and fcrepo-camel-toolbox toolbox release
      1. 4.7.3 release? (compatible with Fedora 4.7.x)
    2. fcrepo4-vagrant 
    3. fcrepo4-docker
      1. Please review this PR: https://github.com/fcrepo4-labs/fcrepo4-docker/pull/35
  5. Next steps for import/export/4→5 migration
    1. Proposal: Two pronged attack
      1. round-tripping 5.x data (add support for versions and webacs)
      2. fcrepo-migrate:   transform 4.7 export into 5.x export
    2. A starting list of Jiras
  6. 5.1.0 
    1. Ready for review
      5. "Check if metadata is available in commons.js" : https://github.com/fcrepo4/fcrepo4/pull/1499
    2. Issues that are ready to be worked:
  7. <your issue here>

  8. Please squash a bug!


  9. Tickets resolved this week:


  10. Tickets created this week:


Minutes

  1. Announcements
    Nothing in particular
  2. 5.0.2
    Off to the races!  Yinlin has taken role of release manager.
  3. Ecosystem release/development policy review
    Yinlin had asked about the fcrepo4/docker project in the context of policies on merging PRs.  There’s no official policy on the labs repositories unlike the extensions or main repositories.  This is justifiable since there’s no guarantee of support for labs repositories’ code. But naturally, people can/should request reviews of PRs as a best practice.
  4. Status on current tools 
    fcrepo-camel and fcrepo-camel-toolbox: the latter has some commits to master intended for release 4.7.3 that Peter’s using locally.  He asks what the RC policy should be there.  Daniel recommends an evaluation period for the toolbox since it is widely used.  A maintenance branch should be created, an RC tag cut, and a RC announcement should be made, but there’s no need for a wiki page, etc.
    Jared suggests that the maintenance branch may be superfluous as there are unlikely to be additional PRs in the interim. The evaluation period will be 1 week.
    There’s a problem building both camel and camel-toolbox with how they reference the parent pom.  Danny Bernstein will explore updates to fcrepo-camel-tests to resolve PAX Exam issue.
  5. Next steps for import/export 4->5 migration
    Daniel’s feeling is that we’re not far away from being able to do this migration.  Two parallel tacks can be pursued.  We can focus on round-tripping 5.x data (exporting version, exporting webacs, and importing versions).  Also, create a new tool that would transform a 4.7 export to a 5 export.  
    It seems reasonable that we’ll make people upgrade to an appropriate version of 4.x before attempting the migration to 5.
    Consensus is that this approach is sound. Documentation will indicate the versions for the export and the import, and wiring in a migration tool at that point will be straightforward.
    Aaron points out that migrating the webacs could be the tricky part, since if there are containment relations between them, these will need to go away, and if there are out-links from any resources to the webacs that are not of the “this is my webac” variety, these will need to be eliminated.
  6. 5.1.0
    Item 6.a.v is of questionable value as it’s for a rather customized case – it’ failing tests, but if the PR authors can fix that, it will all be good.

 

 

Actions