Time/Place

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

• Time: 11:00am Eastern Standard Time US (UTC-5)
• 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 #duraspace-ff chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #duraspace-ff on irc.freenode.net

Attendees 

• Andrew Woods
• Nick Ruest
• Unknown User (acoburn)
• David Wilcox
• Andy Wagner
• Kevin S. Clarke
• Michael Durbin
• Osman Din
• Stefano Cossu

• Unknown User (escowles@ucsd.edu) 

Agenda

1. Committer team and processes
   1. Useful queries: Affects 4.x Unresolved, and Scheduled 4.0.1 Unresolved
2. JIRA clean-up
3. OR2015 Proposals
4. Recent mailing list threads
5. Islandora/F4 update
6. Transform

Minutes

• Committer team and processes
  • Andrew: Fedora 3 committers group isn't relevant to Fedora 4, so we should transition to Fedora 4-based committers group.  Good to review the processes and re-evaluate.
  • Esme: Do we need a separate PMC group?  Or is the committers group we're talking about be the PMC group?
  • Aaron: In Apache groups with large numbers of committers, the PMC group is the key people responsible for releases.  Given the size of the Fedora 4 project, probably not necessary.
  • Andrew: Introducing a new group may be confusing.  Maybe we should look at role of PMC responsibilities and make sure we incorporate those into the committers group.
    • We should setup a wiki page that defines the committer responsibilities:
      • Reviewing and merging pull requests
      • Reviewing received JIRA tickets and promoting appropriate tickets to open status
        • Kevin: Islandora committers do this as a group - would we do that in the weekly committers call, or individually?
        • Andrew: Many tickets are uncontroversial and can be opened by committers individually, but we could review and discuss them and any controversial tickets in the weekly call
      • Rotating release manager, with at least two committers to review each others work and get more people familiar with the release process.
        • We should get a 4.0.1 soon – volunteers?
          • Esme: I'll help with that.
• JIRA clean-up
  • Andrew: We've recently moved from Pivotal to JIRA.  If there are any Pivotal tickets you think should be migrated, please go ahead and create them in JIRA now.
    • Using the existing Fedora JIRA spaces, so there are quite a few legacy tickets.  Many of them are valid, but they probably will not be worked.  Should we keep them?  Move them out of the way?
    • Mike: Should we decide how to deprecate tickets so people know we shouldn't work them?
    • Nick: In Islandora closes them with WONTFIX status.
    • Kevin: Maybe we should give them a label.
    • Andrew: They should have a 3.x-trunk version, so that should be enough to identify these tickets for future review.
    • Esme: Since there are a bunch of tickets, maybe we should just announce to the mailing list that we'll bulk close them all.
    • Andrew: We should be clear not to make people think the team is going to work 3.x tickets.  Does it make sense for someone else to send out the email?
    • Nick: It doesn't have to be Andrew.
  • Andrew: Two recent JIRA tickets should be addressed in the short term, hopefully before the release (esp. 1272):
    
    • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      • Esme: We've seen this at UCSD and may have time to work on it in the next couple of weeks.
    • Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      
      • Esme: maybe we should just use a System property instead of the ObservationManager?
• OR2015 Proposals
  • Andrew: Is anybody putting together a proposal, or think there should be one?
  • Mike: UVa will make a proposal based on local implementation.
  • Nick: Might put in a Fedora 4/Islandora implementation proposal.  But might not since we will have just started.
    • David: You should put in a proposal.
  • Andrew: Considering LDP proposal, and Tech Working Group assessments and outcomes.
  • Stefano: Could be good to have a Fedora 4 use cases panel, similar to CNI panel.
    • Mike: That could be a good fit for UVa, and help report more timely work.
• Islandora/F4 update
  
  • Nick: Officially start on Jan 19th, with Danny Lamb from DGI and Nick from York.
  • Looking forward to working with Camel.
  • Will check in with Andrew bi-weekly to keep him in the loop.
  • Fedora 4 interest group will reposition itself to be the home of the implementation project.  Goal is to have a generic use case for Fedora 3 to 4 migration.