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

20.01.2024 14:50, Daniel Engberg пишет:
> On 2024-01-20T12:40:11.000+01:00, 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?
>
>                  
>     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.
>
>                  
>
>
>                  
>     Sorry again for my poor English.
>
>                  
>
>
>                  
>     -- 
>
>                  
>     Best regards,
>
>                  
>     Vladimir Druzenko
>
>                
>
> It may have come across like one but if that wasn't the intention it's 
> cleared up by now, Either way your suggestion at least for now makes 
> things way too complicated and unmanageable to be practical. Just run 
> the jobs on in Poudriere walk way and do something else util they're done?
>
> Best regards,
> Daniel
>
For example table in wiki with rows:| planned date | port | so name for 
bump | the date the entry was added to the list|
Or file "BUMPS" in root of the ports repo near MOVED, UPDATING and 
CHANGES with same fields.
Remove row after commit bump to main.
It's for real mass bumps like poppler, icu, libvpx, opus, webp, ffmpeg, 
rust, maybe perl5 or change default python and etc.

My both build servers are busy now with build ungoogled-chromium with 
different build options for different hosts (one headless and other for 
use in gui). Next in queue are net/freerdp{,3}.
And I usually build Firefox on a live system - much easier manage build 
options.

-- 
Best regards,
Vladimir Druzenko