On Thu, 05 Aug 2004 07:57:27 +0200, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > That's not how Fedora.US works and not how it should work, IMO. What fedora.us can do/should do as a 3rd party repository outside the fence line... and what Fedora Extras can do/should do/will do cant be assumed to be exactly the same thing. If we want tighter integration that means tighter integration of how things get built and spat out for consumption. You avoid conflicts in process by adopting a coherent development strategy. Focusing policy and political efforts to trickle fixes back down to existing Core releases so a new Extra packages can get built for these older releases drags efforts to fix things in development. Only so many manhours in the day and all that. Its one thing to have a discussion with a package maintainer about going back and fixing a package, its quite another to have a review panel contradict a package mantainers decision to not push an update. And I say, leave these case by case decisions as their judgement call. I really don't think its wise to set up an arbitration panel with authority of this sort of thing, set up to second guess every unpopular update decision that crops up. Anyone who wants that sort of position in the process, is a policy vulture, and we should avoid creating positions of authority like that with the expressed purpose of second-guessing maintainer decisions. If you can't convince a maintainer to release an update package via communication on the public lists or in bugzilla via empassioned logical reasoning or submitted patches, I don't think its worth the concerned political effort to arbitrate it. Just aim for the development tree and the future, instead of arbitrating the past. > > Thats pure optimizism on your part. > No, realism - Remember, I am taking about decisions on a case-by-case > basis. You also suggested building a political structure above the actual maintainers to force them to do things they have already decided against or have made it a low priorization in terms of their effort and time. Let me strongly suggest that building structures like that that rely on authority to review and contradict decisions that individual maintainers should be discussing among themselves is a bad-blood generator. My point is, maintainers of packages are competent enough to make these decisions as they crop up. You might not be excited about the fact that their decisions so far have not been what you wanted, but its the maintainers decision. I have no problem with continuing to leave the decision to produce a known fix just to fix build issues for new packages to the discretion of each package maintainer, without review or mandates from a review board. You said it yourself interests conflict between packagers. I expect them to, I expect those interest conflicts to get worse as more people from the community contribute. And by worse i mean between community contributors and not between a redhat serf toiling away for the corporate interests and a community member. > Face the facts: People still are using FC1 and will continue to use it. > And if Fedora Legacy should work out (Which I am very hesitant to > believe), people will continue to use FC1 for quite a while. People still use rhl6.2. I'm not denying that people still use FC1. What I am trying to point out is the development process for Core has certain timelines already laid down, and those timelines have nothing to do with how long the userbase finds FC1 useful. Just saying that people want new packages for their fc1 systems doesn't make it a worthwhile to prioritize thier creation in the scope of Fedora development. I am facing facts, the life time of Core is so short and development so aggressive that if new Fedora Extras packagers focus on existing Core releases they are going to burn manhours that will be worth far more in the long run if spent working on issues against the Core development tree. Only so many hours in the day and all that. Everyone can agree that having new Extras packages appear against the Core development tree, and having Extras and Core maintainers working things out in that tree is of interest to everyone. I want to make sure the process encourages people working on common interests as a priority.Fedora is already in deep conflict with the desire of portions of the userbase with the timelines chosen for FC, and i think its folly for Fedora Extras development to pander to desire for the userbase to stretch out the usefulness of pre-existing Core releases. Here's my take on conflict resolution regarding new FE packages: New packages built against deps in Core development, trickle them down to existing releases if painless. If not painless have a discussion with the core package maintainers about pushing fixes for existing Core releases. If that discussion doesn't end in a fix... the issue is dead.. and you use Fedora Alternatives to roll replacement for Core packages that potentially break the upgrade path for users who want the new packages. This process encourages: *as much new package development against the devel tree *discussion on a case-by-case basis on how to introduce new packages for existing releases of core *allows for the existance of an alternative set of replacement packages if the fedora extra maintainer wants to do the work, at the cost of potentially breaking upgrade paths for users of those new packages. Users choice, new packages for an older Core release that break upgrade paths, or they wait and get the new packages that work with the next Core release. > > If Fedora Legacy should not work out and if FC+FE should not improve, > I'd expect people to switch away from Fedora. Indeed, I personally encourage people to take a serious look at debian, if they want to have a system where they don't want to have to do a full operating system upgrade/flush every six months. > > It's the way all 3rd parties roll their FC-AddOn repositories. Third parties are free to do what they want. But I'll tell you this.... i was an avid ximian desktop fan as a 3rd party 'repository' in the past. And that experience taught the rolling release model is a fragile untenable solution for a rpm package based distribution. I think ive repeated my points atleast 3 times now, so I'll be refraining from posting anymore on this thread. -jef"mental wheels spinning and turning out circles of logic"spaleta
