On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius <rc040203@xxxxxxxxxx> 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
