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

[Jesse Keating]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 19 January 2004 04:41, Warren Togami wrote:
> ====================================================
> 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.

Correct.  I agree too.

> 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. =)

My original proposal DOES have arch, the $basearch of the url is for the 
i386 vs x86_64 vs ia64.  Thats the reason behind the whole SRPM symlink 
system.

> 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.

The basedir of MY server matters little.  The mirror admins should be 
allowed to make their own base dir(s) and choose at what point in our 
master tree they wish to rsync from.  We should not try to force a 
specific basedir upon them.  In our mirror document, we can suggest a 
basedir of fedoralegacy though.

> 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.

Of course, I'm not going to just go out and implement it today... I have to 
contact the ISP and go through all of that.  I'd MUCH rather get good 
consensus on the system before we move forward.  

> 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.

Duly noted.  Is there any chance you could tell me what time server 
updates.redhat.com syncs against?

> 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'm somewhat tossing/turning over this one.  I've ran across servers that 
don't have the SRPMS and it pisses me off that I have to hunt down another 
fast server that has my content.  To make our master server self 
hosting(well a little beyond) I'd rather have it there, since we can plan 
for the space usage anyway.  Individual mirrors can choose to 
exclude/hardlink this directory if they wish.

> 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.

Yes, that is unfortunate, but they'll probably have to do it again in the 
future sometime if we come up with a good round-robin URL to use that 
points to a few different well supported mirrors to include with the 
default yum/apt config files.  Pointing to a single server can hurt, just 
as Seth about duke's mirror and the effects of yum defaulting to it.  I'd 
rather see a generic URL, like "mirror.fedoralegacy.org" used as a round 
robin to represent a few spread out locations across the world for the 
default.  The end user can live with this, or find the mirror list on our 
site and change it themselves.  Those servers represented by the 
roundrobin would have to have the exact same structure though.

> 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.

Soon, but not before Legacy has their master mirror server up right?  (:

> ==============
> 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.)

LOL!  Good reasons.

> 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.

This is perfect.  My design of the main legacy mirror server should allow 
individual mirror admins or systems to sync only what they need, and 
publish specific config files for use with their mirror(system).

> 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...

Thats agreeable to me, as long as we have our mirrors up first.

> 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.

Can you re-word this a bit?  Almost sounds like you want us to maintain 
security releases for the 3rd party packages you host for 8.0, 9, and 
FC1..  Isn't that a bit beyond the scope of Fedora Legacy?

> 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.

Ok.

> 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.

Yes, it's been in the back of my mind how to handle extras and 
alternatives.  I suppose we'll have to wait and see what kind of content 
makes it in there, and if it's within the scope of Legacy to support such 
things.

> 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.

I like this.  I would like to create an A record for your system, just call 
it bugzilla.fedoralegacy.org.  This shouldn't be a problem no?  In the 
future, can we have our own tracker, instead of Fedora Meta, can it be 
Fedora Legacy with me as the default bug owner?  Your call.

> 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.

Yep, I've been thinking on that too.  I do like your wiki system, I'd like 
to copy it for our use for doc drafts, but our website should NOT point to 
wiki pages for documentation.  They should point to the docbook XML 
formats you mention above.  This way we could also mirror the 
www.fedoralegacy.org site without mirroring the wiki and having problems 
that go along with that.

- -- 
Jesse Keating RHCE MCSE	(http://geek.j2solutions.net)
Fedora Legacy Team	(http://www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam		(www.mondorescue.org)
GPG Public Key		(http://geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFADAgp4v2HLvE71NURAkjKAKCD5AzHCZC8dkCMs9LYHJ4TpadMAgCfZ6/V
tDYS+2dujVsg2u5+hO4jGsw=
=n266
-----END PGP SIGNATURE-----