Re: git: 589aaaeb09b7 - main - multimedia/libvpx: update 1.14.0

On Sat, Jan 20, 2024 at 2:40 PM Vladimir Druzenko <vvd@freebsd.org> wrote:
>
> 20.01.2024 14:10, Mathieu Arnold пишет:
> > On Sat, Jan 20, 2024 at 12:07:03PM +0300, Vladimir Druzenko wrote:
> >> Can we make some kind of schedule for mass bumps of huge ports?
> >> Users who build from ports can schedule upgrade and prevent build something
> >> very big "2 days in a row".
> >> Even if you use binary packages, updating for example virtualbox will entail
> >> a restart (savestate/start) of all virtual machines, and this must be
> >> planned in advance.
> >> If this already exists, please point to it.
> >> Thanks!
> > Hi,
> >
> > I am not sure what you are complaining about.
> > On the one side, it seems that you want to build things yourself and to
> > have everything up-to-date and you upgrade every day.
> > On the other side it seems that you would like to have things not
> > updated so you don't have to rebuild things every day.
> >
> > If you absolutely want to upgrade every day by yourself, then, well, you
> > have to expect to rebuild things, large and small two days in a row once
> > in a while...
> >
> > Use binary packages, there, I fixed the rebuild every day problem you
> > have.
> >
> > Then you say that if virtualbox gets an update, you need to restart
> > your virtual machines, and that it is a problem.
> > Well, it is only a problem if you have the absolute need to upgrade as
> > soon as possible.
> > And in that case, it is your problem.
> > Most of the time, the virtualbox updates are not critical security
> > issues and they can be planned on your side for when it is convenient
> > for you.
> >
> > In any way, nobody forces you to upgrade as soon as there is an update
> > of a port, but in the same way, nothing is going to force the rest of us
> > to not commit to ports because it is inconvenient for you...
>
> Complaining? Why do you think so?
> I just ask about possibility to planning. If no - maybe create one? Maybe somebody have ideas how to do this better and etc?

I doubt it'd possible to implement. How a committer would be supposed
to know when he's clear to push "big" update and when he should wait a
bit?
Now multiply this by the number of "big" ports and you'll see that
everyone start to fight for a "push quant" like hundreds of threads
fight for CPU cores.

> It isn't "complaining".
> Maybe my poor English is the issue…
>
> About virtualbox: I planned update several days ago for yesterday, but today I got bump. Same for firefox - just updated and now I must do it again or get "problems" with prepare update for my ports (freerdp* depends on ffmpeg). If I had known about today's mass bump, I would have planned update for today instead of yesterday. And keep a lot of time…
> I don't need update as soon as possible, but I need to know how long (approximately) I must wait before next mass bump for planning update.

I don't quite get it what's the problem, assuming you're using
pouriere. Recompiling some stuff will just update packages in a
repository, you don't need to do `pkg upgrade` after that.