Page History

...

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
   , but no
   1. . 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 #1. Make sure this is 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
         Provides
         1. the community as well as developers information on what the "target" is for the community as a whole
         . Bugs are obviously a priority but may not be required here as a working product should be an assumption
         1. .
         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 SPEC 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.Something related to asynchronous event stream to the API?
      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 an external module (fcrepo-jms) publishes the events. Distinction
         between inprocess and
         1. between in process and out of process work in the repository kernel, currently everything
         is inprocess
         1. is in process and event publishing is
         an "
         1. an out of process
         "
         1. action.
         But ajs6f
         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 implementers of people implementing Fedora. The reference implementation would naturally produce this SPI for events.
         6. ^^ Makes 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, no one reviews them for him. 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.