User:Jspaleta/Draft

MinGW Repository Draft

Purpose

Making it easier to use a Fedora instance as a development environment for MinGW cross-compiling, by providing a core set of libraries and development tools compiled with MinGW.

Why its own repository

The initial impetus for this effort has been ovirt developers who desire to more easily use Fedora installations as development environments for the work they are doing to build open source cross-platform virtualization tools. There is a recognized potential here for other developers to find value in MinGW compiled payloads for similar reasons. Fedora as a project does have a compelling interest in seeing its distribution widely used as a development environment for cross-platform tools.

However, if that potential is realized, the set of MinGW compiled payloads could be a large number and its not clear that the existing Fedora Project resources can fully accommodate the realized interest in MinGW payloads given the project's focus on building an open source distribution. Resource consumption must be prioritized accordingly to that focus. Cross-compiling development environments are not the primary mission of the Fedora Project. It would be irresponsible for us to make an open-ended resources commitment to a set of MinGW payloads in a way that come come into conflict with our primary mission.

The MinGW repository is an attempt at a compromise. The goal is the allocate a finite amount of space to get the MinGW compiled development environment started as a community initiative which fits inside the Fedora project guidance. The repository itself with be of finite size, with the expectation that as community interest in this repository develops, community members will need to bring additional resources to the effort to grow the size of the repository.

Governance

The MinGW SIG has day to day decisions over the repository. The MinGW SIG is charged with outlining the policies which will be used to handle packaging for the repository. Packaging standards, package submission criteria, packaging reviews, updates policy, etc...

FESCo has ultimate oversight over decisions made by the MinGW SIG and must ratify the policy that MinGW is to use.

It is expected that initial policy decisions will be formed as part of discussion between FESCo, MinGW and the Packaging Committee.

Suggested starting points for a the MinGW packaging policies

• packages to be submitted for the MinGW repository will be treated as new packages instead of as branches of existing packages ( this impacts cvs ).

• MinGW SIG has the option to branch for whatever active Fedora or Enterprise targets they feel they can adequately support. The must at a minimum branch for Fedora Development. This impacts space allocation. If MinGW chooses to support F9, F10 and EPEL5 additional community resource maybe needed in order to accomplish that.

• All packages must first be natively available in Fedora before they can be in the MinGW repo

• All packages submitted for MinGW repo must pass a formal review.

• The review process should be the same used for mainline Fedora packages, and any MinGW specific caveats must be documented in the Fedora Packaging Guidelines.

• MinGW updates will use the same update process, ala bodhi, as mainline Fedora packages do. Note: it needs to be confirmed that bodhi can handle being extended in this manner.

Repository Definition

The repository definition(s) will be included in fedora-release but will be disabled by default. for all Fedora releases that MinGW SIG officially supports. The MinGW repo will make use of mirror manager for its default url in the repo definition. Mirrors will not be required to host this material when they chose to host the mainline Fedora repository.

Spins (such as the developer spin) may choose to pull from this repository, but if they do so they must enable the repository definition by default.

Infrastructure Ticket Reference

https://fedorahosted.org/fedora-infrastructure/ticket/807