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

On Sat, Jan 20, 2024 at 03:22:17PM +0300, Vladimir Druzenko wrote:
> 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.

How does filling in that table work exactly ?
I mean, the only way that can work is if upstream is actually you and
you know that you have decided to release a new version of foobar in 3
days and 12 hours, then you can add to that table "dependants of foobar
will et a revision bump at xxx".
And then, for it to be usefull, you need to find some other committer of
a port that is also a dependency of a port in your list, and that is
also upstream, to synchronise its clock with yours so that you only bump
that shared reverse dependency once. It is not worth the trouble.

In all other cases ports gets updated when the committer (who is doing
that work as a volunteer is their free time) gets to it. We all do our
utmost to keep things working, and it does not really matter to us if
the package builders have to rebuild most stuff every couple of days,
they do it everyway.

It's a nice thought experiment that might work in in a controlled
corporate setup, but it is absolutely pointless where 300+ unpaid
volunteers work in an asynchronous way whenever they have the time.

Ports get updated, when that port provides a shared library that
changes, then ports that depend on that library gets bumped, that's it.
If it happens that one of those ports has two library it needs that get
updated over two days, that's life, it's what chaos theory is about.

-- 
Mathieu Arnold