2015-04-20 12:20 GMT+02:00 Michael Schwendt <mschwendt@xxxxxxxxx>: > On Mon, 20 Apr 2015 11:03:44 +0200, Mario Torre wrote: > >> Hmm, >> >> Security has precedence over even backward compatibility. > > Said that and applied a _tested_ Yum update (a few positive votes in > bodhi) that resulted in Yum not working at all anymore. Worst-case > scenario for all users that rely on Yum for updating their installations. > It has been discussed quite a lot after it had happened. It's just an > example here. (WDYT why three installed kernels are kept?) Well, I guess the yum maintainer is also a developer of yum, he should know better. The case you mentioned may have happened (everybody screws up from time to time, that's ok), but I'm confident this is not always the case. And anyway, this is different really, a security patch generally can cause only minor areas of distress, and they should be "easily" tested, because when you apply security patches you don't also apply a bunch of extra new development things, you only apply (or should so!) the actual security fix. Perhaps we should teach people how to apply security patches instead then? >> The maintainers should be ultimately responsible to ensure that the >> package they maintain is in a coherent state and in theory just >> backporting the security patches. I know that is is often easier said >> than done, but the general rule is security first. > > Cheap talk. ;) It's not cheap talk, this is what we do for the Java packages, it's actual facts. > I've mentioned already that even if it were a patch only, it would still > need a complete new build of the package with build dependencies that may > have changed meanwhile in ways you don't imagine. > > It has happened before that even a "simple rebuild" after just a few > modifications in the package spec file, resulted in broken software. > People say "the packager should notice". What if he/she isn't affected, > and a single tester perhaps isn't either, but many other users are? > Software should be tested, granted. But a security errata, well widespread and understood, with reproducers out in the wild, and in a primary component like Desktop, Browser, Java, Kernel, *can't* linger for two weeks or so without being pushed. >> General users can't really be asked to enable by default a testing >> repository, and you really need to know if an update is a security >> update, rather than a general update. > > Face the facts! > > Many users do install test-updates *unknowingly*, because they install the > same packages that have been offered in updates-testing repo for the > minimum time _without_ any positive tester feedback and with the update > submitter triggering the push to stable manually. What you say is entirely true, this is why Fedora is broken from time to time, but this is wrong!! It means we have a serious problem in Fedora regarding testing, the Karma system alone is broken and not enough! Of course, we can argue forever but the real question is how do we fix it? Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
