On Fri, Dec 09, 2016 at 01:18:31PM +0100, Michael Schwendt wrote: > 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. A strawman proposal: when updates are created, we now fill out a "severity" field. Let's make use of this field, and batch the way that updates are pushed out from updates-testing to updates: - urgent → right now (as fast as we can make it) - high → daily - medium → up to a week delay - low/unspecified → next biweekly batch (I put unspecified together with low, so that people learn to fill out the field ;)) This would make the updates process nicer for users without adding much more complexity. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
