From Fedora Project Wiki
Line 52: Line 52:
* WG: Working Group
* WG: Working Group
* [[Account_System|FAS]]: Fedora Account System
* [[Account_System|FAS]]: Fedora Account System
* API: Application programming interface
* ABI: Application binary interface
* [http://www.cpan.org/ CPAN]: Comprehensive Perl Archive Network
* [http://pypi.python.org/pypi PyPI]: Python Package Index


== Document Structure ==
== Document Structure ==

Revision as of 14:45, 6 January 2014

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:

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
  • API: Application programming interface
  • ABI: Application binary interface
  • CPAN: Comprehensive Perl Archive Network
  • PyPI: Python Package Index

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 updated SPEC files and RPM packages for packages that are already included in Fedora
    • Maintainers will benefit by having less work 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 previews available AS IS.
    • In a way, such repositories would follow the upstream release schedule:
      • As soon as the upstream puts it 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 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]
  • 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)

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