Kevin Fenzi wrote:
> You also don't want updates-testing to even exist right?
That is not true. I want to leave the decision whether and for how long an
update needs to be tested to the package maintainer instead of enforcing
minimum testing requirements in the software, because the software can never
understand the exact context. Removing updates-testing entirely is not what
I want! But this is unrelated to the current issue of artificially delaying
updates that satisfy all the criteria for being pushed to stable.
> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo.
So to save people the download, you make a change that totally defeats the
point of dnf checking for updates every hour to begin with?
> If we update a repo for some minor enhancements it means everyone in the
> world has to pay for that. If we just push all those out every tuesday and
> don't update those unless there's something urgent we save everyone a
> lot of bandwith and us computing time/resources.
This does not work in practice because there are always updates that are not
batched.
> There are definitely more days when there are no updates for a
> particular repo now. Of course there would be even more if you (or those
> who do likewise) wouldn't skip batched, but probibly we need to explain
> why more clearly.
Are there really? The last couple days, there were basically daily pushes
with around 2 updates each.
The batching only makes the daily pushes smaller and not empty, which does
not help at all for reducing repodata download size, because there are still
no repodata deltas implemented.
> because it would be a ton more infrastructure and resources.
Really? Bodhi composes (or triggers the compose of, let's please not discuss
the technical details down to that level) 2 repositories per release at each
push, of which one (updates-testing) already works pretty much the way the
fast track repository would work (updates transit there, but leave again
when they reach the next level). How would adding a third level require a
ton more resources? It would just need some small changes to the Bodhi
implementation ("pushes to batched" would have to be actually pushed, to the
fast track repository) and could otherwise use all the existing mirroring
infrastructure. And users would be able to opt in to getting stable updates
without batching. And even if those users keep the regular repodata
downloads enabled, the downloads for fast track would still be much smaller
than the repodata downloads for all of stable. And having fast track
available would also reduce the proportion of updates that skip batched. (I
know I would think twice about skipping batched for my updates if I knew
that the users have a way to opt out of the batching. Right now, I don't
even consider using batched.)
I see only advantages of such an approach, for minimal infrastructure costs.
Almost everything you need is already there!
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
