On Sat, 24 Feb 2007, Les Mikesell wrote:
Benjamin Franz wrote:
and so on.
This has more to do with squeezing everything on one disk and having to
choose what to eliminate. It doesn't address the new application version
issue. Where do you introduce major-version jumps the first time?
Good question. One way is tag app versions 'obsolete' when the distro base
moves to an incompatible up-version. This is kind of what Legacy did for a
while: You got fixes, but maybe you had to upgrade versions of a
particular package to keep getting fixes for it. For most packages the
difference between 5.8.0 and 5.8.1 is _a lot of bugs got fixed_. It has
stunned me for years that RH has never 're-spun' RHEL3 to upgrade actively
broken versions of software like Perl 5.8.0 to a more 'bug-fixed' version.
You get an incremental distro upgrade rather than a 'rip my system out by
its roots' upgrade most of the time. That lets you reserve the 'OMG'
upgrades for rare occasion every few years where it just isn't possible to
'waterfall' upgrade, rather than every 6 months or so. Without requiring
tons of backporting.
Good ideas spread and come back. Classic 'Bazaar'
to Fedora's 'Cathedral'. You don't see a lot of 'spinoff' from Fedora
because Redhat has clutched it too close to themselves. If you have a
strong enough base community and loose enough control, experimentation
happens automatically.
You don't generally need spinoffs from fedora because you can install
whatever you want from the extras and 3rd party repositories.
I don't buy that. *Every* major distro, including Ubuntu, has 'extra' and
3rd party repository equivalents: It isn't about *need*.
[...]
What you _as a developer_ want are bug reports and fixes. But you aren't
going to get them unless you have enough end users to form the eco-system
that testers and developers spring from. To expect otherwise is to think
that you can raise a crop without the field below it.
What good would it do anyone to have a bug report for FC4 coming in now when
current development has moved on long ago? The developers of the thousands
of programs included in an FC distribution don't develop for any particular
distribution or version, they just keep fixing and adding stuff. Fedora's
purpose is best served by staying as close to the current development work as
possible instead of backporting fixes to a whole set of releases that are now
ancient history.
So go to a 'waterfall' distro model. As new things come out, *put them
out*. The current model is the 'one big update' model. Hundreds or
thousands of changes made at once.
> There is RHEL if you need and can afford support and CentOS if you
> don't/can't. A CentOS user is just as much or more a potential future
> RHEL customer as a fedora user - and RH doesn't get paid any more if use
> fedora. They need people who use and test the added features, but what
> do they gain by doing the extra work of backporting fixes into yet
> another old version.
A large eco-system from which test reporters, bug fixes, developers and
new ideas spring.
Why would these people wanting new ideas be interested in running old stable
releases?
They aren't. But their odds of working with someone who does and becoming
interested in the front edge of the eco-system is proportional to the
*total* number of users of whatever release. A new user will install a new
release.
If you have a hundred uber-developers doing nothing but the wicked cool
leading edge work and that is your entire distro eco-system, your distro
is dead for all practical purposes. You will lose developers faster than
people learn of your system and become interested in working on it.
If you have 10000000 end users entrailing 100000 bug reporters and 1000
developers you have a live and moving system that will grow new developers
from that immense pool of end users on a steady basis.
--
Benjamin Franz
"It is moronic to predict without first establishing an error rate
for a prediction and keeping track of oneâ??s past record of accuracy."
-- Nassim Nicholas Taleb, Fooled By Randomness
