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

[Dennis Gilmore]

Once upon a time Monday 19 January 2004 10:41 pm, Warren Togami wrote:
<snip>
> 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.

Totally agree  the language doesnt make any sense.

> 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. =)
there should definetly be arch in RPMS  all arches should be built from the 
same SRPM right?
> 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.

it needs to be right first time we need agreement on structure that we can 
live with.  as Warren said it is very IMPORTANT

> 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.
could we symlink legacy to legacy-addons on fedora.us for a short period with 
an updated yum package pointing to the new location  perhaps a future feature 
for yum would be to detect 301 errors and adjust its config to suit. 

i like thats it creates the clearness legacy kind of implies  that they are 
updated packages


<snip>
> 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.
i like this idea alot.  the end users should see as minimal change as 
possible.

> 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...
I think it would be fine to remove the trees i was supprised when you put them 
up.

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

Very nice i think at this point fedora.us should cease to release new RH8.0 
packages as it is EOL.  it should however provide security updates for 
existing fedora.us packages.

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

perhaps should the fedora.us tree be considered extras for RH8.0 RH9 and FC1?  
and moved to fedoralegacy.org when product is EOL?

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

as part of the fedoralegacy.org identity i think we should have our own 
bugzilla and wiki  

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

this should be a must.  we should even look at versioning of policies similiar 
to how debian do it  so that updated packages can easily be moved to newer 
versions via a changelog process.  and we know exactly what standard the 
package was written against for instance we have a policy change all pending 
QA packages would need to start over as they wouldnt meet current statndard  
but if they meet standard 1.3  there ok next update they can move to 1.4 

> Comments?  Questions?  Please reply to both lists as this impacts both
> of our projects in the future.
>
> Warren Togami
> warren at togami.com
>
>
> --
> fedora-legacy-list mailing list
> fedora-legacy-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-legacy-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://listman.redhat.com/archives/fedora-legacy-list/attachments/20040119/e7172e75/attachment.sig>