Release date: 27 November, 2014
We are proud to announce the production release of Fedora 4.
Resources
Release Manager
Andrew Woods (DuraSpace)
Contributors
Sprint Developers
- A. Soroka (University of Virginia)
- Anusha Ranganathan (University of Oxford)
- Benjamin Armintor (Columbia University)
- Ben Pennell (UNC)
- Chris Beer (Stanford University)
- Eric James (Yale University)
- Unknown User (escowles@ucsd.edu) (University of California, San Diego)
- Giulia Hill (University of California, Berkeley)
- Greg Jansen (UNC)
- Jared Whiklo (University of Manitoba)
- Jon Roby (University of Manitoba)
- Kevin S. Clarke (University of California, Los Angeles)
- Longshou Situ (University of California, San Diego)
- Michael Durbin (University of Virginia)
- Mike Daines (UNC)
- Mohamed Mohideen Abdul Rasheed (University of Maryland)
- Nigel Banks (discoverygarden inc.)
- Osman Din (Yale University)
- Paul Pound (University of Prince Edward Island)
- Scott Prater (University of Wisconsin)
- Ye Cao (Max Planck Digital Library
- Yinlin Chen (Virginia Tech)
- Yuqing Jiang (discoverygarden inc.)
Community Developers
- Unknown User (acoburn) (Amherst College)
- frank asseg (FIZ Karlsruhe)
- Kai Sternad (Independant)
- Nikhil Trivedi (Art Institute of Chicago)
- Rob Sanderson (Stanford University)
Features
Beta Pilots
One of the strategies for both ensuring that Fedora 4 features address community needs as well as forwarding stakeholder projects was the establishment of Beta Pilots. These projects were limited in scope and timeline to focus energy on identified Fedora 4 capabilities which were exercised in a production-like context.
In the lead-up the the Fedora 4.0 production release, the feedback generated from these pilots was critical in verifying features and surfacing bugs. The outcomes from each pilot project have been published to the wiki, and they will be updated as required:
Technical Working Group
The initial and primary task of the Fedora Technical Working group is to assess the high value/risk areas of the application to determine:
- Quantitatively how these areas perform in production-like scenarios
- Whether these areas are presently positioned to meet community requirements, or need to be architecturally revisited
Plans
The plans for assessing the top four areas follow:
- REST API plan [27]
- Performance plan [28]
- Clustering plan [29]
- Preservation worthiness plan [30]
Outcomes
The results and recommendations of the priority areas of assessment follow:
- REST API outcomes [31]
- Performance outcomes [32]
- Clustering outcomes [33]
- Preservation worthiness outcomes [34]
References
[27] https://wiki.duraspace.org/display/FF/API+Partitioning [28] https://wiki.duraspace.org/display/FF/Assessment+Plan+-+Performance [29] https://wiki.duraspace.org/display/FF/Assessment+Plan+-+Clustering [30] https://wiki.duraspace.org/display/FF/Assessment+Plan+-+Preservation+Worthiness [31] https://wiki.duraspace.org/display/FF/Outcomes+-+REST+API [32] https://wiki.duraspace.org/display/FF/Outcomes+-+Performance [33] https://wiki.duraspace.org/display/FF/Outcomes+-+Clustering [34] https://wiki.duraspace.org/display/FF/Outcomes+-+Preservation+Worthiness
References
[1]