English Portuguese (Portugal)
The _latest_ repositories
The _latest_ http://kojipkgs.fedoraproject.org/repos/[repositories] contain packages for various build 'tags' as they arrive in the Koji build system. They are not https://git.fedorahosted.org/cgit/mash/[mashed], a process which principally handles multilib, and using them can cause various problems, in addition to overloading Fedora's development servers. It is almost always a better idea to cherry-pick new builds from https://fedoraproject.org/wiki/Koji[Koji] or https://fedoraproject.org/wiki/Bodhi[Bodhi] via their web interfaces or command line tools.
Repositories FAQ
Why is _updates_ only used after the stable release?
As described above, updates for both Branched pre-releases and final, _stable_ releases go through the _updates-testing_ process before being moved to a _stable_ repository. Before the final release, they are placed in the _fedora_ repository. After release, they are placed in _updates_.
The reason for the difference is that we want to have a record of the exact 'state' of a given Fedora stable release. That is, at the time a Fedora release is declared to be done at a https://fedoraproject.org/wiki/Go_No_Go_Meeting[Go/No-Go Meeting], we consider the state of the release at that time to be the canonical definition of that release, and we wish to preserve a record of that state. For a stable release, the tree containing the _fedora_ repository *is* that record, and the _fedora_ repository it contains is the canonical record of the precise _frozen_ package set that formed the main part of that stable release.
Since we wish to maintain this _frozen_ state for the _fedora_ repository, we cannot place updates directly into it. The necessity for the _updates_ repository therefore becomes obvious - we need a place to put updates to stable releases that is outside the _frozen_ state of the release.
Before a stable release occurs, this mechanism is not necessary. Before the release is declared to be done, there is no _frozen_ state of the release: effectively, the whole Branched development process is _working towards_ what will become the _frozen_ state of the release, so of course package builds for the Branched release land directly in the _fedora_ repository.
Why is _updates-testing_ enabled by default in pre-releases?
While Branched development releases and stable releases both use an _updates-testing_ repository together with the Bodhi update feedback system to stage packages before they reach the release's _stable_ state, it is enabled by default in Branched, but not in stable releases.
The reason is that the purpose of the _updates-testing_ system is somewhat different in each case. For stable releases, the system's goal is to prevent broken updates reaching the general Fedora user population. In most cases, Fedora systems are expected to have the _updates-testing_ repository disabled. Some QA testers then enable the repository on testing systems to try out the updates and provide feedback. The testers perform the job of making sure the updates are OK before they reach the general user population.
When it comes to a Branched pre-release, the expectation is that anyone who installs it wants to help test it: we effectively consider anyone running a Branched release to be a tester. The function of _updates-testing_ is different in this case. There is not a 'general user population' of Branched users who run with _updates-testing_ disabled, and are protected from problematic updates by the group of update testers. Instead, _updates-testing_ in Branched serves other important functions.
The main purpose is to insulate _image builds_ from potentially problematic changes. Branched images - nightly images, and the Alpha, Beta and GA (Final) _milestone_ builds and their https://fedoraproject.org/wiki/Go_No_Go_Meeting[test compose and release candidate builds] - are built from the _stable_ packages, that is, only those in the _fedora_ repository, not those in _updates-testing_. In this sense, _updates-testing_ protects not a set of users, but a set of _builds_, from potentially destabilizing changes. Especially when we are building an Alpha, Beta or GA release, we need to be able to reduce the amount of change in the package set between composes in order to produce an image of high quality. The _updates-testing_ mechanism allows for that: during https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes], new builds can be sent to _updates-testing_, but cannot move from there to _stable_ (_fedora_) without special circumstances. In this way, we can work on release images while not preventing packagers from sending out builds.
For this and other less important functions, we need as much feedback as possible, so it makes sense to have all pre-release testers have _updates-testing_ enabled by default, and encourage them to provide feedback through Bodhi.
See a typo, something missing or out of date, or anything else which can be improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.