Fedora Engineering/FY14 Plan
Red Hat tracks a lot of things by "fiscal year". Every public company has a different definition of when the "fiscal year" begins and ends, but for Red Hat, it begins on March 1, and ends on the last day of February. The "fiscal year" numeric naming is attached to the latest calendar year in the "fiscal year". Red Hat Fiscal Year 2014 (henceforth abbreviated as "FY14") begins on March 1, 2013, and ends on February 28, 2014.
This document is Fedora Engineering's "working plan" for FY14.
At this time, no new hires are planned for FY14.
Fedora Engineering is constantly working on any number of initiatives, but for FY14, our focus will be primarily on four initiatives. These projects are both "big" in scope and in importance (and arguably, in time to complete). We reserve the right to add additional projects, big and small, and to postpone or abandon projects. We also are interested in feedback from the Fedora Community on these projects, both in concept, and as they progress towards completion.
These projects are summarized here for simplicity, in each case, further documentation about the projects will be forthcoming (and linked from here). Interested community members (at any level) should contact the corresponding Project Lead.
HyperKitty: Mailing List Improvement Application
Project Lead: Aurélien Bompard
Started in FY13, HyperKitty will provide a consistent, real-time, forum style interface for Fedora's mailing lists. Fedora Community members who prefer a mailing list model for communication can continue to receive mail, while Fedora Community members who prefer a forum-style interface to communicate can do so, and both groups are seamlessly communicating with each other.
The point of this effort is not to argue the pros and cons of forums vs mailing lists, but rather, to accept that both have merit and embrace them for what they are and what they can bring to Fedora.
Notable UI concepts:
- Support threading
- Robust search
- User karma (possibly thread karma?), where user and/or post "scores" would be sent in mail headers for possible client side filtering (and UI filtering, e.g. "Don't show me topics started by users with < $FOO karma" or "Hide comments on topics from users with < $FOO karma"). This would be a case where the forum interface would be richer than the mailing list side.
For more details, see: https://fedorahosted.org/hyperkitty/
100% Fedmsg Enablement
Project Lead: Ralph Bean
Ensure that every Fedora infrastructure service is generating messages via fedmsg. Including bugzilla. All of these messages will be logged in Datanommer, and statistics can be generated from this msg history.
Project Lead: Tom Callaway
Create an ecosystem where users and contributors can earn digital badges for actions performed in the Fedora infrastructure space and locally on their Fedora OS installation. Additionally, have "quests" where when multiple specific badges are earned, Fedora Account holders will earn tangible real world prizes (hats, shirts, exotic sports cars, etc, etc).
This serves to help us motivate community involvement in Fedora and to generate useful statistical data about local user and contributor usage.
Monthly Bundled Updates
Project Lead: TBD
Generate an additional stream of updates, which is composed of all updates in "updates stable" from the critical path with one week remaining in a month. Then, QE will test those updates as a set, to ensure that basic testing reveals a reliable OS at that point in time. Then, those updates will be pushed into a repository, and local Fedora client tooling will see it and treat it as a single update to be installed (e.g. "The Fedora 18 June 2013 Update).
Security updates will still go out asynchronously. All other updates not in this monthly bundle (and not security) will be considered "optional", and the user will not be "nagged" to update them, unless they add packages to a configurable whitelist.
Users who wish to remain on the current "firehose" update model may do so.
The packager workflow for generating updates should not change at all as a result.
Application GUI Installation
Project Lead: Ryan Lerch
In conjunction with the GNOME Desktop team, overhaul the current PackageKit GUI interface and provide a clean and extensible Application (not package) installer with a powerful search and the ability for Fedora Account holders to give feedback (karma and comments).
yum will remain available (and used as the backend, unless technically impossible) for CLI usage.
This will almost certainly require backend infrastructure in addition to local Fedora client changes.
Project Lead: Luke Macken
There are a lot of issues with the existing Bodhi deployment and its functionality, and a general consensus of how to move forward with the next major revision of the Bodhi Update Management software.
Proposed enhancements include:
- Ensure that a package and its dependencies are always pushed together as a single update unit, even if the update unit is maintained by multiple parties, pushed initially as independent updates.
- Ensure that packages are not pushed which would break dependencies within Fedora (or EPEL).
- Improve the "karma" system
- Cleaner Web UI
More details can be found here: https://fedoraproject.org/wiki/Bodhi/2.0
A rather old mockup can be found here: http://lewk.org/img/bodhi-20-frontpage.png
[IMPROVED KERNEL QA]
Project Lead: Dave Jones
Setup a dedicated Fedora Kernel QA environment, where manual and automated tests can be run against Fedora Kernel builds to minimize (or at least identify) regressions and bugs earlier.
These ideas don't have owners, nor do they have any guarantee of actually happening this year, but if you're looking for something to do, these would be appreciated.
- A Meeting App - next meetings, hot topics, who's saying what, etc. using meeting bot logs
- Teach meetbot how to handle voting
- Spin Master - analysis of what packages added/removed in each spin for each revision
- Automate nightly spin compose tasks, currently a manual process.
- Openshift - Possibly move some simple apps into openshift, get FAS running in Openshift as it's needed for all of our other apps to run
- The idea is to have development environments for our apps that people can pull up quickly and easily with minimal input from the fedora admins. Then, for the simple apps, we can additionally have those apps run in openshift in production (which cuts down on work that we need to do to maintain those servers and deployment as an rpm, etc)
- Improve Fedora Hosted - Something more like gitorious, gitlabhq, allura