Env and Stacks/Product Requirements Document

Fedora Environment and Stacks Product Requirements Document.

About this Document

This PRD (Product Requirements Document) is an evolving document, created by the Env and Stacks Working Group as part of the process for designing the Fedora.next. The PRD is not real PRD, because this WG is not creating a product, but merely list of task of various technologies, which could be once used by Fedora products.

Authors

Contributors to this document include:

• Marcela Maslanova

Reviewers & Contributors

The following people have contributed to the development of this document, through feedback on IRC, mailing lists, and other points of contact.

Community Information

The Env and Stacks WG mailing list is located here.

Minutes and logs from IRC meetings related to the development of this document should be listed here as the document evolves.

Approval History

There will be added new requirements by other products in the future. The first version should contain what our WG believe we should do.

• version 1

Tracking of Progress

While Fedora uses the Changes Process to track changes in the distribution, those changes are typically described as details of changes to a specific package, or the introduction of a specific package, rather than as a piece of a larger feature set.

This document could possibly be used to do any or a number of the following things:

• Provide a secondary location where changes are tracked (which seems like a lot of overhead to me)
• Provide a location where overall Feature Progress is tracked, via periodic cross-checking against Change pages; this could be either in a standalone section, or simply attached to each Feature description.
• Scope out how features are expected to progress over a number of releases.
• None of these things.

When we more fully determine how to most efficiently track progress, the pointer to where that tracking is done, and/or the description of or process by which we do the tracking is formalized, should be documented in this section in lieu of what is currently written here.

Document Purpose and Overview

What this document describes

This document lists tasks, which must be finished for other products and for making development in Fedora easier.

The purpose of this document is to encompass the following goals:

• What can be done for developers and users in environment (development tools, documentation, examples, latest tools, stable tools)?
• What is needed by other products from the Env and Stacks WG?

Document Conventions

Definitions and Acronyms

• PRD: Product Requirements Document
• EPEL: Extra Packages for Enterprise Linux
• CI: Continuous Integration
• SCL: Software Collections
• NTH: Nice-to-have
• BZ: Bugzilla
• WG: Working Group
• FAS: Fedora Account System
• API: Application programming interface
• ABI: Application binary interface
• CPAN: Comprehensive Perl Archive Network
• PyPI: Python Package Index

Document Structure

The document provides a list of tasks, which are to be completed next year. Other products or users can ask for other requirements, e.g. to package something into an image and mount it somewhere. Complete features can be added into Fedora products, e.g. an SCL into a Fedora product.

Tasks

The following is a list of tasks with a short description.

Testing/additional repositories

• Many features from this WG will need an additional repository, which has to be hosted somewhere (on copr, koji tags). Also, a policy for enabling the repository must be defined.
• A repo with packages only for the build. It might help some developers to just build their package without maintaining the build dependencies.
• Repositories with a looser policy than the current Fedora Packaging Guidelines. Examples of what a looser policy would allow would be bundling libraries, overriding things in Base/Core. It is important to note that these repositories would still need to follow Legal/Licensing Policy as the goal for these repositories is to eventually end up being officially distributed by Fedora.

Automation

• Additional repositories with automatically updated SPEC files and RPM packages for packages that are already included in Fedora.
  • Maintainers will benefit from having less work with updating the packages, since they would just need to review the automatically updated package and import it into rawhide.
  • Users will benefit from having the latest versions of software available. Clearly, the users will need to be informed that the provided packages are a preview available AS IS.
  • In a way, such repositories would follow the upstream release schedule:
    • As soon as the upstream makes it available on e.g. CPAN, PyPI, it would be available in the repository.
    • We would need to handle major updates with an API/ABI bump. Checking for ABI/API breakage could be done automatically with api-checker.

• Automated packaging
  • The general idea is to enable easier/quicker packaging of upstream software by generating SPEC files for the packager automatically.
  • Various tools for automatic packaging already exist (e.g. the *2spec and *2rpm tools), so we will use them as a starting point.
  • The critical non-automated part of the packaging and review process that will remain manual will be the licensing checks.
  • By leveraging copr, we could have automatically updated repositories generated automatically from upstream sources.
  • jzeleny is working on other automatic packaging tools.

• Automated package review tools
  • Development of a new service where package reviews would happen from start to finish [1]:
    • No Bugzilla
    • Automatic FAS integration (one could automatically mark reviews that need sponsors)
    • Guided (self-)review
    • Inline comments (like gerrit)
    • FedoraReview integration
    • pingou plans to work on such a tool [2]

• Taskotron
  • tflink is working on it

• Automation of fedpkg/git/bodhi/BZ connection such as:
  • Automatic comments in BZ after git commit that would include a commit link, commit message and could also move the bug to modified.
  • Create a tag automatically in git as soon as the build is successfully built in koji, so maintainers can easily access the content of the particular build using pure git.

Build systems

• COPR & koji
  • COPR able to build an SCL
  • koji - a number of improvements for developers (buildlogs, etc.), in co-operation with the koji upstream.

SCL

• SCL in Fedora.
  • Pending in FPC. Most probably each SCL will be added into Fedora as a system-wide change.
• SCL in SCL.org from COPR.
  • Possible to use 3rd party repos for various projects.
  • Almost ready.
• scl-utils v2
  • New features out of scope for this version of the PRD.

CI

• Out of scope (going to take a long time to be included in Fedora, maybe even the inclusion for this group).
  • AutoQA - co-operation with Fedora QA.
  • Jenkins - upstream projects for Fedora should use http://jenkins.cloud.fedoraproject.org/

Documentation, guidelines

• Wiki pages.
  • Currently lacking any usable structure, lots of abandoned and outdated content, thus not being very helpful.
  • Look into creating a better structure, improve the related wiki page categorization.
  • Keep the Packaging: namespace, the official Packaging Guidelines are and will be maintained by the Packaging Committee members.
  • Archive the outdated/duplicated/unneeded wiki pages (outside the Packaging: namespace).
  • Motivate people to create new content (with badges, swags,...).
  • Improve the search on Fedora wiki.
  • Add more references to formal documentation (see below).
• Formal documentation.
  • Some people prefer to use a single document to learn about concepts and tasks rather that browsing through a number of wiki pages. Wiki content may not feel qualified and may not invoke the same trust as formal documentation.
  • pkovar will be working on a new Packager's Guide, to help people getting started with RPM packaging for Fedora and EPEL. The goal is to share as much content as possible with downstream RHEL/EPEL documentation, using the same format and toolchain (DocBook, Publican).
  • The guide will be mostly based on the Fedora wiki pages/HOWTOs. It will reference additional resources on the wiki (esp. in the Packaging: namespace) and/or other content where appropriate.
  • An outdated draft is here: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Packagers_Guide/index.html
• SCL
  • Continue to improve the SCL packager guide.
  • It currently lives at http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/index.html
  • Using the same format and toolchain as the Packager's Guide and other Fedora guides, it currently shares content with the RH version of the same book at access.redhat.com.
  • Look into upstreaming the guide to SCL.org if it turns out not to be possible to share most of the content with the version at SCL.org or access.redhat.com (due to limited resources).

DevAssistant

• Support for Docker.io images.
• Setup environments.