RPM submission procedure

[Jef Spaleta]

> 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