Hacking modversions

Dave Jones davej at redhat.com
Wed Mar 2 00:51:07 UTC 2005


On Wed, Mar 02, 2005 at 12:16:14AM +0000, Mike Hearn wrote:

 > - Being more conservative about what changes are pushed into
 >   fedora-updates, and just putting them off for FC4. In particular I was
 >   kind of surprised to see such huge changes in security patches!

http://fedora.redhat.com/about/objectives.html
"#3. Do as much of the development work as possible directly in the upstream
 packages. This includes updates; our default policy will be to upgrade to new
 versions for security as well as for bugfix and new feature update releases of
 packages."

backporting fixes to older releases is a real killer. Especially when you
consider that you're taking code from one release that has had no testing
at all with another. (Quite nasty if for eg a security hole in the VM is
found, and there's been significant change between $oldrelease and current).
Every time a fix gets backported, you're also introducing the possibility of
getting something wrong due to some other unrelated change.
I've seen this happen to multiple vendors, and no amount of review catches such gotchas.
 
 > Yes, that means that some new features may not get in until the next
 > Fedora release. So be it.

The rebasing to new releases isn't about adding the new features.
It's done to lower maintainence overhead. Supporting 3 releases at the same
time becomes a lot easier when 2 of them share the same kernel (and one is
only a point release away).

 > Online updates should be about bugfixes and
 > security patches IMHO, not about adding or removing features once the OS
 > is deployed.

If something got removed without a viable alternative, then that's
a regression that should be reported. Examples ?

		Dave




More information about the fedora-devel-list mailing list