From Fedora Project Wiki
No edit summary
Line 35: Line 35:
= Document Purpose and Overview =
= Document Purpose and Overview =
== What this document describes ==
== What this document describes ==
This document should list of tasks, which must be finished for other products and for easier development in Fedora.
This document lists tasks, which must be finished for other products and for making development in Fedora easier.


The contents of this document should seek to accomplish the following goals:
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 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?
* What is needed by other products from the Env and Stacks WG?


== Document Conventions==
== Document Conventions==
Line 59: Line 59:
== Document Structure ==
== 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.
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 =
= Tasks =
List of tasks very shortly defined.
The following is a list of tasks with a short description.


=== Testing/additional repositories ===
=== 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.
* 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.
* Repo with packages only for build. It might help to some developers to just build their package without maintenance of build dependencies.
* 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 of these repositories is to eventually end up being officially distributed by Fedora.
* 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 ===
=== Automation ===
* Additional repositories with automatically updated [[How_to_create_an_RPM_package#SPEC_file_overview|SPEC files]] and RPM packages for packages that are already included in Fedora
* Additional repositories with automatically updated [[How_to_create_an_RPM_package#SPEC_file_overview|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.
** 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 previews available AS IS.
** 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:
** 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
*** 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.
*** We would need to handle major updates with an API/ABI bump. Checking for ABI/API breakage could be done automatically with api-checker.


Line 80: Line 80:
** The general idea is to enable easier/quicker packaging of upstream software by generating SPEC files for the packager automatically.
** 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.
** 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.
** 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.
** By leveraging copr, we could have automatically updated repositories generated automatically from upstream sources.
** jzeleny is working on other automatic packaging tools.
** jzeleny is working on other automatic packaging tools.


Line 88: Line 88:
*** No [[Bugzilla]]
*** No [[Bugzilla]]
*** Automatic [[Account_System|FAS]] integration (one could automatically mark reviews that need sponsors)
*** Automatic [[Account_System|FAS]] integration (one could automatically mark reviews that need sponsors)
*** Guided (self)review
*** Guided (self-)review
*** Inline comments (like [http://code.google.com/p/gerrit/ gerrit])
*** Inline comments (like [http://code.google.com/p/gerrit/ gerrit])
*** [https://fedorahosted.org/FedoraReview/ FedoraReview] integration
*** [https://fedorahosted.org/FedoraReview/ FedoraReview] integration
Line 97: Line 97:


* Automation of fedpkg/git/bodhi/BZ connection such as:
* 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
** 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 build is successfully built in koji, so maintainers can easily access content of the particular build using pure git
** 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 ===
=== Build systems ===
* COPR & koji
* COPR & koji
** COPR able to build SCL
** COPR able to build an SCL
** koji - improvement for developers (buildlogs, ...), in co-operation with upstream of koji
** koji - a number of improvements for developers (buildlogs, etc.), in co-operation with the koji upstream.


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


=== CI ===
=== CI ===
* Out of scope (long time for inclusion into Fedora maybe even this group)
* 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
** AutoQA - co-operation with Fedora QA.
** Jenkins - upstream projects for Fedora should use http://jenkins.cloud.fedoraproject.org/
** Jenkins - upstream projects for Fedora should use http://jenkins.cloud.fedoraproject.org/


=== Documentation, guidelines ===
=== Documentation, guidelines ===
* wiki pages
* Wiki pages.
** create system in wiki pages
** Currently lacking any usable structure, lots of abandoned and outdated content, thus not being very helpful.
** motivate people to create content (badges, swag,...)
** Look into creating a better structure, improve the related wiki page categorization.
** improve search on fedora wiki
** Keep the Packaging: namespace, the official Packaging Guidelines are and will be maintained by the Packaging Committee members.
* more from pkovar, hhorak?
** 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 ===
=== DevAssistant ===
* support for Docker.io images
* Support for Docker.io images.
* setup environments
* Setup environments.

Revision as of 17:34, 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 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]
  • 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).

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

DevAssistant

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