Fedora Extras vs. CLOSED RAWHIDE

[Jeff Spaleta]

On Thu, 05 Aug 2004 07:57:27 +0200, Ralf Corsepius <rc040203 at freenet.de> 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