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