new daylight savings time

[Benjamin Franz]

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