On Thu, 8 Dec 2016 19:45:55 +0100, Christian Dersch wrote: > On 12/08/2016 07:26 PM, Dennis Gilmore wrote: > > I would like to see us stop pushing non security updates to updates from > > updates-testing entirely and do it in monthly batches instead. we would push > > daily security fixes and updates-testing. However this would make atomic host > > 2 week releases much less useful, as there would be no updates except for once > > a month. > > > > > What do you expect from monthly batches? I *really* don't like things > like "patchdays". Besides security fixes there are also other situations > like small but annoying bugs… IMHO the current model with updates repo > works fine, I see no reason to make a change here. The apparently random flow of poorly tested "rushed out" updates is a major drawback of Fedora's current release process. It reminds me too much of the infamous dumping ground for packages. We jump over many hops to release a "stable" distribution. Then we take it apart as we unleash more and more updates, which move away from what has gone through the Alpha/Beta freeze and testing process. Too many packages get changed and invalidate all the testing of previous releases. We also change the repo metadata too often due to this flood of updates. Users already wonder why the metadata need to be refreshed so often? One packager pushes a minor version update for some niche market font, for example, and the repo changes for everyone. As much as I'd like to retain the possibility to publish hotfixes -- provided that both the package maintainer *and* any testers (if needed) know what they're doing, and if the package maintainer in particular runs the affected release of Fedora *and* the update -- something is wrong about the updates release process. Patch days make it possible to publish update collections in a way the entire batch can be evaluated better, because it will be a more clearly defined step from A to B rather than randomly released pieces every couple of days. The process overhead will be significant, however. Everyone will want to get some minor update or random version upgrade to be included. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
