Linux is not about choice [was Re: Fedora too cutting edge?]

[Jeff Spaleta]

On Jan 9, 2008 12:27 PM, Jesse Keating <jkeating at redhat.com> wrote:
> And if we had chosen that, it likely still wouldn't be where it is
> today, because it wouldn't have had the exposure.  It was functional
> for the vast majority of uses and the exposure got more and more things
> fixed on it.  If there was an alternative then everybody would just
> switch back to the old method, and no bugs would get filed and no
> corner cases would get discovered.

We need to build an accurate perception as to what we are offering in
our releases.  When we have the manpower to support it
we drive technologies forward aggressively.  We need to build the
perception that our releases aren't just consumables, but they instead
collaborative partnerships will our users to meet the goals of driving
long term value into the open source software stack.  We need to build
the perception that when you choose to use fedora, you are choosing to
be a part of the collaboration, and not just taking a product off the
shelf giving it a spin.

In areas where we have Fedora contributors who are active upstream
developers, we tend to make integration decisions in release N which
have the best potential for long term benefit for release N+1, N+2 and
out into the future (especially in the area of hardware interaction).
We know our process is not regression intolerant. But our process
accommodates that fact by having an aggressive update process so
people suffering hardware regressions can obtain fixes in a responsive
manner.  This isn't a policy, or a set of rules, this is how our
development culture operates in broad brush strokes.  It would be
deeply disruptive to the project to attempt to suppress this essential
nature.

So how do we fix the perception that this is a bad thing? How do we
attract users and contributors who are comfortable with some level of
regression, for the sake of long term benefit?

Naively, I would suggest continuing to enhance our Feature-scoping so
that it includes known or suspected regression areas.  And we need to
be able to have our developers who are aggressively driving new
technologies into our releases, make public commitments that they will
work to address regressions as part of the update process.  We can't
make guarantees, but we can certainly project a perception that our
developers care about hardware regressions and are willing to work
with people to fix them.

-jef