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
