Fedora Legacy Launch Plan (draft 2)

[Warren Togami]

The following is the Fedora Legacy Plan (draft 2).  This plan will 
impact the future of older fedora.us repositories so fedora.us 
developers need to pay careful attention.  The purpose of this draft is 
mainly to make the plan public and invite questions, but we are 
essentially pushing forward with this plan NOW.

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 at togami.com