Re: git: a4245a4c6ce1 - main - devel/boost: update to 1.87.0 release (+)

On Sat, 15 Feb 2025 11:41:03 +0100
Daniel Engberg <diizzy@FreeBSD.org> wrote:

> On 2025-02-15 07:32, Cy Schubert wrote:
> > In message<6c28366e-b7c2-47b7-9a04-13b963ac6889@freebsd.org>, Matthias
> > Fechner
> >   writes:  
> >> Dear Dima,
> >>
> >> Am 14.02.2025 um 05:17 schrieb Dima Panov:  
> >>>       devel/boost: update to 1.87.0 release (+)
> >>>       
> >>>       New port devel/boost-mpi-libs, Message Passing Interface library,
> >>>       for use in distributed-memory parallel application programming.
> >>>       
> >>>       In this release Boost have dropped some long-time-ago deprecated asio  
> >> facilites  
> >>>       Seehttps://www.boost.org/doc/libs/1_87_0/doc/html/boost_asio/history.h  
> >> tml for details.  
> >>>       
> >>>       Release Notes:https://www.boost.org/users/history/version_1_87_0.html
> >>>       Sponsored by:   Future Crew, LLC  
> >> so you really think it is a good idea to break kea and icinga2 by this
> >> upgrade without giving the maintainers a change to prepare an update?  
> > I don't think that was a good idea either. When broken ports are discovered
> > during an exp-run it's the responsibility of the committer to either fix
> > the ports or open PRs, assigned to the maintainers, to address the problems.
> >  
> >> I personally had to rollback this change as kea is crucial as it
> >> distributes IPs to all my servers and icinga2 is used to monitor all
> >> system/services.  
> > I'm importing kea 2.7.6 (development branch) as kea-deevl. It addresses the
> > problem. I will backport the fix to the 2.6 branch (kea).
> >
> > boot-libs 1.87 fails to patch. I've emailed the committer and cc'd this
> > list. All we've heard are crickets.
> >
> >  
> >> Maybe give it next time a little more reaction time for the consumers of
> >> this lib?  
> > Agreed.
> >
> > Certainly disappointing.
> >  
> >> Gruß
> >> Matthias
> >>
> >> -- 
> >>
> >> "Programming today is a race between software engineers striving to
> >> build bigger and better idiot-proof programs, and the universe trying to
> >> produce bigger and better idiots. So far, the universe is winning." --
> >> Rich Cook  
> 
> Hi,
> 
> As much as breakage is bad I do understand fluffy's decision due to how 
> we currently handle updates of libraries that touches multiple ports in 
> tree as it's a very tedious and time consuming effort. Much of it lies 

As maintainer of binutils, I get this. Had the previous to last
binutils gone in this way I doubt anyone would have come to my defense
to cut to the chase and be done with it.

> in the fact that some have very strong feelings about not pruning the 
> tree for various reason. I fully recognize the fact that everyone have 

Using this reasoning and extrapolating forward, one can't prune the
tree of the isc-dhcpd replacement (kea) and fall back to isc-dhcpd.

> different opinions, needs etc and portmgr even tried to make a generic 
> policy (which never got finalized to my knowledge)of it but in the end 
> of the it causes a lot of hold ups, eats a lot of time and some 
> compromises needs to be made to make progress. I'm not saying that 
> bulldozing is the way to go but I would also say cut him some slack 

It may or may not be but it certainly feels like this was bulldozed
through. The number of ports flagged as broken by this commit was
greater than other commits, like base LLVM or binutils. In those cases
I've been assigned PRs, or have assigned PRs, to fix ports that have
broken by an update. Searching bugzilla I don't see any evidence this
happened here.

> because trying to "align" the tree for each boost release is well near 
> impossible without turning it into a project that's ongoing for months 
> and by that time we're very much behind. If you want some historical PRs 
> have a look at on the "trying to please everyone" approach:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261302
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278420
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279705 (I'm very close 
> to say lets go and mark the rest as broken to move forward at this point)

Sure, if they've been broken for a few weeks and the maintainer has
made no effort to fix them, then sure, mark them broken and deprecate
them. A deprecation notice is certainly enough to light a fire under a
maintainer to act on a PR. And if the maintainer is not a committer, or
even if they are, assign the port back to ports@.

> 
> ...to mention a few.
> 
> To be fair, I think a two week heads up is reasonable (generic timeout) 
> before pushing it or at least for replies due to how frequent upstream 
> development is and how much time we can "spare/demand" from various 
> committers.

I think a little longer. Waiting two weeks for an acknowledgement is
plenty of time. There needs to be evidence that the port is being
worked on, else mark it broken, deprecate it, and assign maintainership
to ports@. But, there needs to be no evidence of the breakage actively
being worked on.

And, BTW, this is how I handle these types of situations at $JOB. It
works!

> 
> Best regards,
> 
> Daniel



-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0