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:

Attendees 

Agenda

  1. Technical Priorities

  2. Bug Prioritization

    type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. F4 GitHub Organizations - "Becoming an fcrepo4-exts project"
  4. Ticket review process - who does it?

  5. ...

  6. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  7. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

  1. To understand what we are trying to implement and focus on for next 6+ months. Trying to get consensus on the listed priorities.
    1. Clustering no longer a medium term priority. No pickup after some preliminary testing.
    2. Make sure that the difference between #1 (as the Fedora API) and #2 & 3 (that are priorities on the reference implementation of the Fedora API) is made clear on any public facing documentation.
      (jared's note: I may have combined two separate thoughts in this one point.)
    3. Unknown User (escowles@ucsd.edu): Where does bug fixing fit into the technical priorities? Performance scale is an obvious fit but others don't have a clear tie in.
      1. The purpose of the document is to:
        1.  provide the community as well as developers information on what the "target" is for the community as a whole.
        2. A way to determine prioritization of issues that may have some support or are difficult to decide
      2. A bug is only a bug because it does not work according to the associated specification (and expected behaviour)?? (jared's note: not sure if this was an AND... or AND NOT...)
      3. Different people have different priorities and when they encounter problems, those problems are as important as any other priority on the list.
    4. Consensus with the main services of the Fedora API (priority #1)
      1. Under transactions we need a way for people to efficiently perform a batch of operations against the repository.
      2. Unknown User (acoburn): Is whether Fedora publishes some sort of event stream a priority?
        1. A. Soroka: It does not publish events, it provides events and a currently core module (fcrepo-jms) publishes the events. Distinction between in process and out of process work in the repository kernel, currently everything is in process and event publishing is an out of process action.
        2. A. Soroka would not like to add this to the kernel.
        3. Andrew Woods: If we did not publish events then a lot of the F4 functionality goes away.
        4. A. Soroka: does not feel we lose priority, sometimes things are not as needed as they first appear. The kernel creates events "in process" and we are committed to an SPI to allow "out of process" publishing of those events.
        5. We have good standards to tie our externally facing processes, but the internally facing processes don't have the same standards. In places where there is no external spec we need to create our own spec and publish it. This makes it something that can be relied on by people implementing Fedora. The reference implementation would naturally produce this SPI for events.
        6. Clear standards also help make it clear when a "bug" is a "bug" and not just a variance from what someone thought should happen.

  2. Red items should be an immediate priority, green are nice to clean up. Very serious bugs!

  3. Please review the document and make comments on that wiki page.

  4. When Andrew Woods does a ticket, there is no process for reviews from other committers. Maybe establish a more formal process to make sure all tickets are reviewed in a timely fashion.

  5. Final questions: A. Soroka: When will the technical priorities document become public? In the next week or so, float by IRC, then leadership team, and finally the broader community.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.