Fedora Extras vs. CLOSED RAWHIDE

[Jeff Spaleta]

On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius <rc040203 at freenet.de> wrote:
> As I already tried to outline, I can image several technical approaches:
> 
> 1) In exceptional/special cases, Fedora.us/FE should be permitted to
> replace packages from FC if they break other FE packages or are unusable
> in general.

I'm confused... if a package is already in FE how can a lack of an FC
update break it?
Any package published in FE should be building against the active FC
release(s) to even get published.  So I'm trying real hard to see how
a lack of an update in FC is going to break already published FE
packages.  And generally unusable packages that have no dependent
packages should be thrown out of Core completely to save space in
Core.
But i think everyone will agree that everyone will disagree about what
'generally useless' means in general.

Now if you want to talk fixing an FC package to make it easier to get
a new FE package published... i counter with maybe the only real way
forward is for FE maintainers to be tracking the development branch as
much as possible for new FE packages, instead of shoehorning the
packages to work with an active FC release.

> 
> 2) RH/FC commits their packagers to listen to FE's package update
> demands and to benevolently consider to release bug-fix updates once
> such a demand pops up.

And what happens when FE package1 demands an FC update.. and that FC
update breaks the hacks in FE package2, package3 and packagee5? Do we
have the different FE package mantainers duke it out? This issue will
always be grey. Certainly a if an FE package needs new update to fix a
security issue, working that out would be important.
But anything else, is grey. I for one would be not so happy to see
60megs of updates to download on my desktop system just for
buildrequires bugfixes.

> 3) Don't change anything. In this case, FE should not release packages
> that trip bugs which can not be worked around without very little
> effort.

I'm totally fine with this. I think long-term I think everything for a
'release' would run smoother if FE packagers were tracking the
development tree as much as possible.
And update to the active FC when needed(and my definition of needed is
very strictly security related) or when painless.

> Though others might find 3) acceptable, I am opposed to it, because it
> is little helpful to users and contributors, and, in  cases where
> work-arounds are possible, it means playing with symptoms and spoiling
> upstream development with hacks.

its only spoiling if you consider the current FC release as a living
breathing squirming thing to be toyed with. If you see the current FC
release more like the shedded husk of a cicada
or the molted skin of a snake, then you start thinking its not really
best to focus new efforts there. If FE packagers do their updates
against devel branch, and FE 'releases' are synced with FC 'releases'
we can perhaps avoid making work for ourselves by working against the
timescales and branch tagging of core.

-jef"instant gratification seems to be an expectation with FE"spaleta