On Fri, Dec 9, 2016 at 11:30 AM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > 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 ;)) I did something like this many moons ago. In the end, it was a wash. Push frequency without repository separation basically means the frequency is irrelevant because when the updates show up is entirely dependent upon when the user runs 'dnf update' or similar. > This would make the updates process nicer for users without > adding much more complexity. That is actually untrue because of how our updates backend process works. Doing it this way requires multiple pushes for the same cumulative set of updates and it requires tooling to be written to do the filtering. So it is less complex for users, but more work for those processing the updates. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
