Future of fedora.us and fedoralegacy.org (was Re: Legacy mirror structure)

[Warren Togami]

Chuck Wolber wrote:
> 
>>My proposal is to run a master mirror server for FL.  An ISP has offered
>>rackspace and bandwidth for such a beast.  The layout I envision is
>>this:
>>
>>download.fedoralegacy.org/legacy/$releasever/SRPMS/
>>download.fedoralegacy.org/legacy/$releasever/SRPMS//base
>>download.fedoralegacy.org/legacy/$releasever/SRPMS/updates
>>download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing
>>download.fedoralegacy.org/legacy/$releasever/SRPMS/legacy-addons
>>download.fedoralegacy.org/legacy/$releasever/$basearch/base
>>download.fedoralegacy.org/legacy/$releasever/$basearch/updates
>>download.fedoralegacy.org/legacy/$releasever/SRPMS/updates-testing
>>download.fedoralegacy.org/legacy/$releasever/$basearch/legacy-addons
> 
> 
> I'd be interested to see us include lingual and architecture support in
> those paths. Recall that the redhat storage paths are:
> 
> $releasever/en/os/$arch
> 
> I think they make a great deal of sense, and will prevent us from having 
> to play "two-path-monte" or create ugly symbolic link farms if we need to 
> make changes later.
> 
> 

====================================================
The following are my personal recommendations regarding the mirror 
structure.

IMHO, since long time ago RH merged all languages into a single 
distribution, I highly doubt we will go back to having multiple 
distributions for different languages.  The earlier 7.x supported by 
Legacy is only a special case.  For this reason I would suggest not 
using a language directory.  Keep one layer of complexity out.

arch directory does make sense though.  I am surprised they are missing 
from your original proposal you were the one that suggested arch i386 
and x86_64 in IRC. =)

I am in agreement with previous posters in suggesting making the basedir 
"fedoralegacy" rather than just "legacy".  This makes things more clear 
for mirror maintainers.

I would highly suggest going through at least another day of discussion 
and consensus for the mirror structure, since this is IMPORTANT.  You 
need to live with it forever.

One note about when you write the Fedora Legacy mirror HOWTO document. 
Make sure that your package timestamps match exactly RH's main mirror, 
and make sure that mirrors use rsync option "-a" which will preserve 
timestamps among several other wanted options.  This should allow mirror 
admins to use the hardlink tool (contained in the legacy-addons channel) 
to consolidate tons of space with their existing redhat and 
fedora.redhat.com mirrors.

I would suggest NOT holding the base SRPMS within the mirror tree on the 
Legacy master mirror.  Just keep the directory empty.  They are almost 
totally never needed, and if a developer really does need it, they can 
get it easily enough from any of the thousand existing RH/Fedora mirrors.

I am intrigued by the channel name "legacy-addons" rather than "legacy" 
currently used by fedora.us.  It would be a little confusing to have 
both names exist.  I suppose I could rename the channels on fedora.us, 
but unfortunately all existing users pointing there will need to upgrade 
their yum or edit their configurations.

I do admit however that "legacy-addons" is less ambiguous and very clear 
that it contains only add-ons, while "updates" does not.   Thus I am 
thinking this is a good idea.  Sorry existing users... but read below, 
since I am thinking to soon remove 7.2 and 7.3 completely from 
download.fedora.us for reasons of redundancy.



==============
Just to clarify about why download.fedora.us is maintaining a separate 
mirror structure from fedoralegacy.org.  Below outlines my thoughts for 
future maintenance and distribution of fedora.us, and how it will 
continue to operate after FC2 when the Extras development and 
repositories are moved to fedora.redhat.com.

1) fedoralegacy.org's own mirror structure allows a separation of 
governace, security, build system, and responsibility of sysadmin 
duties.  (Community no longer needs to rely on Warren.  Warren does not 
go insane.)

2) I plan on automatically rsyncing legacy's updates and legacy-addons 
channel into the appropriate directories of download.fedora.us.  This 
will allow existing fedora.us users to continue to get updates from 
repositories they had been using since 9 months ago for RH8, RH9 and 
FC1.  Other existing repositories with an "updates" channel like 
freshrpms.net could do the same from legacy's "updates" and continue to 
serve existing users in a similar manner.
Existing users need only import the new FEDORA-LEGACY-GPG-KEY.

3) It is true that download.fedora.us 7.2 and 7.3 will be completely 
redundant to fedoralegacy.org's 7.2 and 7.3 since fedora.us never did 
make add-on packages for 7.x.  For this reason I am thinking to simply 
remove the 7.2 and 7.3 trees from download.fedora.us.  I'm hurting for 
space anyhow...

4) download.fedora.us will continue to serve RH8, RH9 and FC1 add-ons in 
the Extras channels stable/testing/unstable for users who wish to use 
them, while continuing to benefit from "updates" which are copied from 
legacy.  fedora.us will indefinitely maintain security updates for RH8, 
RH9, FC1 Extras within the existing download.fedora.us tree, with the 
help of the Legacy team.

5) download.fedora.us will no longer be needed by FC2, since Extras will 
be moved to fedora.redhat.com.  Then fedoralegacy.org will continue to 
handle "updates" for each distribution in their own mirror structure.

6) When FC2 goes EOL, fedora.redhat.com's Extras might also be frozen. 
Thus fedoralegacy.org may need to add an "updates-extras" channel in 
order to serve security updates to FC2's Extras.  We will not need to 
discuss this until sometime during 2005 though.

7) fedoralegacy.org can continue to use bugzilla.fedora.us.  That 
instance of Bugzilla is now being maintained professionally and should 
remain stable as a result.  New products/components can be added to the 
Bugzilla to uniquely support Legacy development.

8) fedoralegacy.org should eventually fork their documentation into 
their own Wiki for draft & editing purposes while policies are discussed 
and agreed upon.  Then maybe later docbook XML for nicely formatted 
finalized documents.  This policy & process documentation writing is 
another job needed for fedoralegacy.org, and another chance for 
volunteers to contribute.

Comments?  Questions?  Please reply to both lists as this impacts both 
of our projects in the future.

Warren Togami
warren at togami.com