I would certainly prefer it was designed to make it easy for other >
people
to keep their archive sets compatible. FC1 core doesn't advertise 5 year binary compatibility - and doesn't have it, but nobody is proposing to completely ignore compatibility and breaking third party repository code.
Too late. If the ideal you are looking for is to preventing breaking 'pre-existing' 3rd party repository structures and processes. It's too late. Changing the name and the numbering to Fedora Core 1, from the rhl line has already affected how 3rd parties interpolate. If the ideal is keep 'pre-existing' 3rd party repository structures from having to do ANY changes to how they package things...its too late for that discussion. And frankly in my mind...thats a non-starter discussion to begin with...simply because 3rd party repos is objective 12..in the list.
My interpretation of objective (12): "Create an environment where third party packages are easy to add and positive encouragement and support exists for third party packaging."
doesn't speak at all the the idea that 'pre-existing' 3rd party repository efforts are going to interpolate well. My interpretation of objective 12 is colored by the higher priorties of objectives 4, 6, and 9 which speak to the idea of building a development environment and toolset for the community to use. I see that toolset as including technical tools and policy guidelines for 3rd party repositories to 'choose' to use to 'choose' to be compatible with Fedora Core. I personally don't see making it a priority to bend over backward to make sure 'pre-existing' repository policies and structures work well with Core, especially in light of the fact that 3rd party repository and packaging in objective 12 on a 15 objective list. I'd much rather concentrate on a comprehensive community packaging standard and policy that ANY 3rd party could choose to re-implement to ensure being in sync. If pre-existing 3rd parties feel a heavy burden to continue using their current policies and procedures to support their established userbase, then it's going to be unlikely that they will choose to use whatever development environment comes out of the Fedora process..simply because their priority list is very out of sync with Fedora's stated prioritization of things.
-jef