Read the following post for details about what this means for Fedora Legacy users and developers.
The below guidelines and procedures go a long way to launching a viable project largely based upon already proven & existing fedora.us infrastructure and procedures, with minor modifications necessary for Legacy.
***** Fedora Legacy Launch Plan (draft 2) *****
The Fedora Legacy project will use fedoralegacy.org as the home page.
This home page will contain:
1. Documentation & HOWTO
Since Legacy will use the existing download.fedora.us structure and mirrors, HOWTO usage would basically be exactly how people us fedora.us today, except perhaps only "os" and "updates" channels.
2. Listings of package update details
3. link to bugzilla.fedora.us
This bugzilla serves as both the problem tracker and package submission & QA.
4. Mailing lists including announce, discuss, and devel
We need to request adding these lists at redhat.com.
fedora.us will eventually become the Fedora Legacy project.
This means that all of the existing project infrastructure will be
leveraged in the community based maintenance of Legacy packages on EOL
distributions. As mentioned above download.fedora.us and the many exisiting mirrors will carry the Fedora Legacy packages within the "updates" channel. Repository users have the option of using the fedora.us Extras stable/testing/unstable repositories too.
GPG use requirement
Like the previous fedora.us development, all Fedora Legacy developers are required to use GPG in a proper manner in all communications of substance. This allows messages and packages to be verifiable back to individuals. Most importantly this enables building the corpus of historical evidence necessary for anyone to read, verify GPG signatures, and decide based upon the contributor's good advice if they are to be trusted or not. This is part of the "web of trust" concept.
Fedora Legacy project will continue to use bugzilla.fedora.us in almost exactly the same way currently used by fedora.us Extras. The only difference will be the package release tags and location within the repository will be different from the fedora.us Extras packages.
The %release tag contains only a number incremented from the release number of the previous EOL distribution package, then ".legacy" appended to the end to make it clear that this is a Fedora Legacy package.
evolution-1.2.2-5 This is the latest official RH update evolution-1.2.2-6.legacy This would be a theoretical package name of the Fedora Legacy update.
Some cases like the kernel package has a distribution version at the end. The Fedora Legacy package naming will be treated accordingly.
kernel-2.4.20-27.8 kernel-2.4.20-27.9 kernel-2.4.20-28.8.legacy kernel-2.4.20-28.9.legacy
Legacy packages are to be published in the RPMS.updates channel along
with the existing official updates from the EOL distribution. This
means that existing users of fedora.us mirrors will continue to benefit
from security updates. Users can choose between using only the base "os" and "updates" channels for the core packages, or adding the Extras channels stable/testing/unstable for more functionality and package choices.
Package development priority is is focused on mainly security updates of the core distribution "os" and "updates" channels. We will keep an eye on security advisories for the Extras packages but they are lower priority than the base distribution. Network exposed services have the highest priority, while client applications have lower development priority.
Fedora Legacy packages in the "updates" channel may NEVER upgrade the version. Instead these packages may be only patched, unless consensus dictates that we must do otherwise. Updates are allowed primarily for security reasons, but sometimes bugfix updates can be allowed if consensus agrees it is serious enough.
Legacy packages in QA testing will be placed in the fedora.us updates-testing repository for functionality and stability testing before publication. We still need to discuss how we need to change the publication requirements and "trusted" status for Legacy packagers as the scope and people involved differ greatly from the fedora.us Extras development. Please read the existing fedora.us Package Submission & QA procedure page and suggest ways to modify that procedure for Fedora Legacy.
http://www.fedora.us/wiki/PackageSubmissionQAPolicy fedora.us Package Submission & QA Policy
What does this mean for the future of fedora.us and Extras?
Extras will probably no longer exist at fedora.us for newer distributions after being merged into fedora.redhat.com Extras around FC2 time. fedora.redhat.com probably will not have three levels of Extras (stable/testing/unstable) but I personally am pushing for two levels (stable/unstable).
Existing Extras packages for older distributions served by Legacy will sometimes be updated in version by the Extras package maintainer in the case of popular client applications like gaim. Historically fedora.us Extras packages have been of nit-picky top quality, but this will wane. Extras packages will not change much mainly due to lack of interest and time by developers, and new additions will be disallowed after a certain cut-off date. It is the responsibility of all Fedora developers and users to watch for security advisories and report when package updates are needed in the Extras repository.
Warren Togami warren@xxxxxxxxxx
