Time/Place

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

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
• International toll free:  http://www.readytalk.com/intl 
  
  • Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
  • Once on the call, enter participant code 2257295
• IRC:
  
  • Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #fcrepo on irc.freenode.net

Attendees 

• A. Soroka 
• David Wilcox 
• James R. Griffin III
• Andrew Woods
• Unknown User (acoburn)
• Yinlin Chen  
• Unknown User (daniel-dgi)
• Unknown User (escowles@ucsd.edu)
• Nick Ruest
• Bethany Seeger
• Kevin S. Clarke

Agenda

1. 4.3.0 Release planning

   1. Outstanding items? 
   2. Otherwise, code freeze
2. migration-utils, where do we stand?
3. WebAC activity
4. New-developer hack event
5. Reworking of fcr:fixity 
   1. Currently it is a Fedora-ism
   2. Currently there are not audit events from fixity runs

6. F4 core, extras, and labs (mailing list thread)

   1.  What are the "core" Fedora capabilities/projects?
   2.  Which projects are always included in any given release?
   3.  Should we decouple the version number schemes of optional projects from core releases?
      1. A. Soroka: Yes, there is no advantage to locking them.
   4.  Should optional projects share the same "org.fcrepo" package namespace?
      1. A. Soroka: Only if the responsibility for them is the same as the responsibilities for core (that is, owned by the same people and accompanied by the same promises)
   5. What are the criteria for graduating from (1c)? - Practices from Islandora? Hydra?
      1. A. Soroka: There should never be any expectation that projects will graduate.
   6. What is the policy for deprecating a project from (1a) or (1b)?
   7.  What should the name of a third GitHub organization be, if such an organization is needed?
      1. fcrepo-extras
      2. fcrepo-ext
      3. fcrepo-flaky
      4. fcrepo-chum-bucket

7. ...

8. Current Priorities

   Performance Single subject fcr:metadata as a container Point-like objects Camel RDF serializer Migration-utils Wait for Mike Bugs

9. Tickets resolved this week:

10. Tickets created this week:

Minutes

1. 4.3 Release is slated for tomorrow.  Thanks Nick!

• Aaron has two tickets for OSGi that will get squeezed in for the release (one for auth and one for core).  After that, it's a code freeze.

2. Mike isn't present to speak about migration-utils, but Nick chimed in

• Danny will get allocated onto migration-utils with his remaining time on the 7.x-2.x Islandora project
• 7 remaining tickets,
• From the Isandora perspective 1554 (Audit trail mappings) and Datastream Properties (needs a ticket) mapping are highest priority

3. Web ACL work is continuing, with two upcoming sprints.

4. Feedback on hackfests:

• Do a larger event 9-5?  Or smaller 'hackhouse' event?
  • Esme has done both types of events.  Both serve different needs.  Formal training builds skills, hackhouse helps people get familiar with project and each other.
  • Nick has lead day long hackfests.  Either would work for him.
  • Bethany (being new) is curious about introductions to contribution.
  • Kevin (via IRC) said that small hackfests are more enjoyable, but that formal training would be more beneficial in getting people contributing.

5. Reworking of fcr:fixity FCREPO-1407

• Ticket has dropped off the radar.  Call for interest in ticket.  Unfortunately Esme had just left meeting early.
• Ticket will remain that way for the time being

6. F4 Core, extra, labs

• Still need criteria from graduation from labs to extras or core.
  • In Islandora, there needs to be a formal declaration of intent to bring into core.  A component manager must be declared and perform their duties, and if they fail to do so, or the code fails testing, then it is not included in core and is demoted into labs.
  • Danny said not to get bogged down into code coverage statistics.  Having a dedicated maintenance team/person and having user acceptance testing is more important.
  • Need a good policy on versioning and declaring owners/maintainers after 4.3 release.
• What is the deprecation policy?
  • In Islandora, after deprecation things get shuffled into a special github org just for that
  • Danny said to give people a year after deprecation before removal from codebase, with minimal maintenance in that time frame.
  • Andrew proposed demotion into labs after deprecation period has ended
  • Adam proposed 6 months instead of a year for the period
  • Nick feels there should be a distinction between labs and deprecation.  Don't let labs become the trash can.
  • General consensus is after deprecation is declared, there is a grace period, after which the repo is moved to a deprecated github organization.