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