Bug backlog - now and future. Some proposals.

Tim ignored_mailbox at yahoo.com.au
Sun Mar 23 06:50:28 UTC 2008

Jim Cornette:
>>> In order to advance progress for the releases a short life cycle is
>>> needed to ensure programs do not remain static and outdated.

>>  I do not agree.  Programs can advance and change, without the OS having
>>  to change.  OS and applications are separate things.

Jon Stanley:
> Where do you draw the line here?  The kernel, for example gets "lots*
> of updates, most of them not for the sake of the fact that we can
> update it, but rather that there were bugs that users reported that
> were fixed.  Do we not fix bugs that actually exist for the sake of
> stability for users that have not experienced them?

That's a different direction than the point I was countering:  That some
believe that applications cannot and will not progress if you don't
change the OS, as well.  It's a furphy.  Applications can change and
advance, lots, while still running on the same unchanged OS.  They're
two very different things.

> I hate to say it, but RHEL may be the product that you're looking for,
> where this exact thing happens.  Between update releases, only
> critical/security bugs are fixed.  Anything that's not a showstopper
> waits til the next update relasee.

I have played with CentOS, but it *seems* to suffer from the problem I
outlined above.  People looking after the applications seem to
artificially stagnate them.

I'll say it again, the OS and applications are separate things, you can
advance them individually.

(This computer runs FC7, my others run FC4, FC5 & FC6, in case that's
 important to the thread.)

Don't send private replies to my address, the mailbox is ignored.
I read messages from the public lists.

More information about the users mailing list