Fedora Extras vs. CLOSED RAWHIDE

[Ralf Corsepius]

On Tue, 2004-08-03 at 22:43, Elliot Lee wrote:
> On Tue, 3 Aug 2004, Ralf Corsepius wrote:
> 
> > Sometimes, RH developers close PRs as "CLOSED RAWHIDE" instead of
> > releasing a bug-fix update, i.e. they postpone bugs to FC-upstream and
> > leave them as "known bugs" for the current FC-release.
> 
> Ralf,
> 
> It's a good issue that has come up before. Users sometimes want to stick
> with their installed releases while still getting fixes for the bugs
> important to them.
Exactly. It's exactly what I do. Though I've set up testing machines
with FC2, I will be sticking with FC1 on "production machines" for the
foreseeable future.

> The problem all comes down to limited resources and priorities. There
> are
> only so many hours in the day, and given the goals of the Fedora Core
> distribution (which include being on the leading edge of open source
> technology), it is generally more important to spend those hours improving
> the development tree than backporting fixes for old releases.
You're probably aware that the objectives of  individual contributors to
FE don't necessarily match with those of RH/FC. 

This implies 
* FE can only work if RH/FC's interests sufficiently intersect with
those of contributors.
* FE and RH/FC interaction can only work if both parties are willing to
compromise and are willing to allocate resources.

> There are probably ways that things can be improved without hurting future
> development, so by all means stick with the issue! You're already on your
> way to finding out what the constraints are and where the solution may be.
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.

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.

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.

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.

Technically, I don't see much difference between 1) and 2):
* Both require coordination and mutual attention between RH/FC and FE/FE
contributors.
* 1) would require less resources on RH/FC's side (It's a form of
outsourcing to the net).
* In singular cases 1) could make FE packages unusable for RHEL. If
that's an objective of RH, 1) is no alternative from RH's point of view.
* 2) would be less risky, because a RH packager can be presumed to be
more familiar with a package than an external contributor/volunteer.
* 2) would require RH to be _willing_ to allocate resources.

In an ideal world, 1) and 2) could be implemented as exchange of a
little communication. However, I don't expect this to work in all cases.
Worse, I'd expect both approaches to cause "bad blood" between both
groups in cases of disagreement.

Therefore, I fear it will be inevitable to implement formal procedures
for "update requests". Technically, "update requests" probably could be
implemented via bugzilla triggering a machinery inside of RH.
To solve "conflicting cases", a jury/committee/tribunal could be
implemented.

Another topic that has not been discussed in this thread yet, is the
impact of a distribution's life time on such "update requests".
"Fedora Legacy", you might answer now, but ... I never understood how
this is supposed to work.

Ralf