On Thu, 20 Dec 2007 15:58:52 +0000 (UTC), Kevin Kofler wrote: > > It is circumvented too easily. Packagers raise the karma for their own > > packages. Release people don't reject quick pushes from testing to stable, > > which are not security related or critical. > > Why should they? The answer is above. To enforce that packages stay in updates-testing for a certain period of time unless they are marked as security/emergency. We need to give the user community time to take notice of test-updates, take pre-cautions (e.g. use multi-boot or a test-machine) and actually help with testing updates. > Release engineering plays an important role in Fedora, but > they are a small team compared to the huge number of package maintainers, they > cannot really be expected to know more about the package than its maintainer. > The maintainer should be the one who knows best what to push. For many software projects and their release habits, as a packager you need to be very careful about what upstream releases you take for a stable distribution that has undergone a long development/testing cycle. Even so-called "minor" updates often break in lots of ways. The steady stream of updates where upstream releases are packaged and published in less than 24 hours is too much of a risk in my view. > There are already complaints that Fedora is too bureaucratic, having to > justify "criticalness" of each upgrade makes it worse, not better. That's easy. The spec %changelog entry already ought to explain why the update is important. It's the many hundreds small/minor/unimportant updates which fill the updates repository and drift away from the original release of the distribution. It leads to a scenario where after firstboot you are offered so many packages that you're annoyed. Anyway, the rest of your mail only tells me that you disagree and that it is unlikely that we will agree on it ever. I don't see any need to comment on any excerpts in detail. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list