Fedora Extras, Fedora Core CVS Open!

[Michael Favia]

> I think that the problem is clear. Red Hat/Fedora Core have different
> goals than independent repositories. The goal of Fedora Core is to have
> a stable set of packages for a release which then don't evolve much - we
> only fix bugs with security impact or other serious bugs. 
<snip>
> That's much different from independent repositories such as Dag's
> because they have the goal to deliver packages of new versions of
> various software to as many distributions as possible. For this it's
> much better to have one spec file with macros.
> 
> So the question is, will Fedora Extras be more like independent
> repository or more like the Fedora Core. Or it could depend on package.

This is the first response to address the real issue in my opinion. If 
fedora extras is meant to be on par with fedora and maintain a forward 
looking policy (eg new releases for current FC and security fixes only 
for past FC) then the choice seems fairly easy.

The real question is: "Is the independent packaging community willing to 
follow this mantra of 'moving forward' and thus abandoning backwards 
compatibility without maintaining separate spec files"?

If not is the cost of regressions/complexity in the spec files (that 
they want to use) greater than the benefit of having those individuals 
on board?

Perhaps the real issue we need to be asking is while it is very nice (i 
repeat: very nice and greatly appreciated) to be able to install new 
versions of various software on my FC1 boxes, how inline with the goal 
of the fedora project is that? I would argue that it doesnt really have 
a place, at least not in fedora extras. But, we need the independent 
package managers onboard and to do so we either need to convince them of 
the benefits of a forward looking approach to this distro or we need to 
allow at least some the complexities they bring with the skills they 
honed in more stable and longer life cycle distros.

I personally believe that the fedora extras should compliment Fedora 
Core by adopting the same style of release pattern on a wider array of 
packages that, for various reasons arent included in Core. The other 
goals such as backwards compatibility seem to have a place in a Fedora 
Legacy project.

<Important Part>
Maybe maintaining 2 spec file sets is the best solution:

1 for Fedora core that is simple an focuses only on the current release
1 for Fedora Legacy that includes macros and attempts to bring extended 
support to the fedora core distribution

That way the barrier to entry for innovation remains low and individuals 
dedicated to maintaining historical perspective can do so efficiently. I 
confess ignorance on the details of such an implementation but it seems 
a likely solution for everyone involved from my point of view.
</Important Part>

happy holidays,
mf

-- 
Michael Favia            michael.favia at insitesinc.com
Insites Incorporated       http://michael.insitesinc.com