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 should list of tasks, which must be finished for other products and for easier development in Fedora.

The contents of this document should seek to accomplish 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 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

Document Structure

Document will provide list of tasks, which will be done in next year. Other products or users can ask for other requirements e.g. package something into some image and mount it somewhere. Completed features can be added into Fedora products e.g. some SCL into some Fedora product.

Tasks

List of tasks very shortly defined.

Testing/additional repositories

• Many features from this WG will need additional repository, which has to be hosted somewhere (on copr, koji tags). Also policy for enabling the repository must be defined.
• Repo with packages only for build. It might help to some developers to just build their package without maintenance of 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 of these repositories is to eventually end up being officially distributed by Fedora.

Automation

• Additional repositories with automatically generated packages from upstream that are ALREADY in Fedora.
  • Maintainers can benefit from such packages, which could be reviewed and imported into rawhide.
  • Users can benefit from latest versions of software.

• The automatic packaging
  • There exists various tools for automatic packaging, which works quite well (cpanspec, ...). Let's start with these.
  • 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 commit link, commit message and could also move the bug to modified
  • create a tag automatically in git as soon as build is successfully built in koji, so maintainers can easily access content of the particular build using pure git

Build systems

• COPR & koji
  • COPR able to build SCL
  • koji - improvement for developers (buildlogs, ...), in co-operation with upstream of koji

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-utils2
  • new features out of scope for this version of PRD

CI

• Out of scope (long time for inclusion into Fedora maybe even this group)
  • AutoQA - co-operation with Fedora QA
  • Jenkins - upstream projects for Fedora should use http://jenkins.cloud.fedoraproject.org/

Documentation, guidelines

• wiki pages
  • create system in wiki pages
  • motivate people to create content (badges, swag,...)
  • improve search on fedora wiki
• more from pkovar, hhorak?

DevAssistant

• support for Docker.io images
• setup environments