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


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



  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


  • 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):
      • FCREPO-1258 - Getting issue details... STATUS
        • Esme: We've seen this at UCSD and may have time to work on it in the next couple of weeks.
      • FCREPO-1272 - Getting issue details... STATUS
        • 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.