From nobody Sat Feb 15 14:23:39 2025 X-Original-To: dev-commits-ports-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4YwB3y607Bz5nd68; Sat, 15 Feb 2025 14:23:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta003.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YwB3y2nThz3Nsk; Sat, 15 Feb 2025 14:23:42 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id jGp8tJr7p9JM2jJ53tb4mv; Sat, 15 Feb 2025 14:23:41 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id jJ51tR0xnJhBPjJ52tNX58; Sat, 15 Feb 2025 14:23:41 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=QY3Fvdbv c=1 sm=1 tr=0 ts=67b0a36d a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=IkcTkHD0fZMA:10 a=T2h4t0Lz3GQA:10 a=AIPdC31oAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=YxBL1-UpAAAA:8 a=tCxC1ASJeR82Y-O12lwA:9 a=QEXdDO2ut3YA:10 a=dlEfVpbE7yEA:10 a=_4_jBa1hx1EA:10 a=5478VIVnyzLWgM9zoUhq:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 7784A635; Sat, 15 Feb 2025 06:23:39 -0800 (PST) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (Postfix) with ESMTP id 38835405; Sat, 15 Feb 2025 06:23:39 -0800 (PST) Date: Sat, 15 Feb 2025 06:23:39 -0800 From: Cy Schubert To: Daniel Engberg Cc: Matthias Fechner , Dima Panov , ports-committers@FreeBSD.org, dev-commits-ports-all@FreeBSD.org, dev-commits-ports-main@FreeBSD.org Subject: Re: git: a4245a4c6ce1 - main - devel/boost: update to 1.87.0 release (+) Message-ID: <20250215062339.7f9e8a91@slippy> In-Reply-To: References: <202502140317.51E3HpsO022259@gitrepo.freebsd.org> <6c28366e-b7c2-47b7-9a04-13b963ac6889@freebsd.org> <20250215063244.3A5863AD@slippy.cwsent.com> Organization: KOMQUATS X-Mailer: Claws Mail 3.21.0 (GTK+ 2.24.33; amd64-portbld-freebsd15.0) List-Id: Commit messages for all branches of the ports repository List-Archive: https://lists.freebsd.org/archives/dev-commits-ports-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-ports-all@freebsd.org Sender: owner-dev-commits-ports-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfLDupzfRJHKMdWlDvwOaP1QPmJanOvp/ruanuk5K03THcZwH1gFNCJjsGiHBf1auCGusLy3fQwX5QYpwPSzWzpg9XYJ9PijK8Ts3EWO5qXe5KzM625Pu h2nvf3+IQIiHsbCWaL3zUF0QgsEqwfLrQDFVZoouybuHJ6SphjyImEzDvOs9PTvnuMKKLNfdr+8mw97vnnyS+lU5J6zHcWzHzO+yd1QR7o9F8C7IzPS3O2qD meBwXJD77W2ID5ZiNccMaC00qCeNyXI+isgcfnoL7QCUdLuzc3GsPlNLM4YJuG5qqs04ZMv47eJt6wq7eTJJ/Z+mGIYPvzQcFvTEdjQCtT3AV2U8fgHUXUZA eTXorBWzQ2JD4TUx3LF6YzgbkecIQOUCh7cn9/6PAYdxyu+p48c= X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4YwB3y2nThz3Nsk X-Spamd-Bar: ---- On Sat, 15 Feb 2025 11:41:03 +0100 Daniel Engberg wrote: > On 2025-02-15 07:32, Cy Schubert wrote: > > In message<6c28366e-b7c2-47b7-9a04-13b963ac6889@freebsd.org>, Matthias > > Fechner > > writes: =20 > >> Dear Dima, > >> > >> Am 14.02.2025 um 05:17 schrieb Dima Panov: =20 > >>> devel/boost: update to 1.87.0 release (+) > >>> =20 > >>> New port devel/boost-mpi-libs, Message Passing Interface librar= y, > >>> for use in distributed-memory parallel application programming. > >>> =20 > >>> In this release Boost have dropped some long-time-ago deprecate= d asio =20 > >> facilites =20 > >>> Seehttps://www.boost.org/doc/libs/1_87_0/doc/html/boost_asio/hi= story.h =20 > >> tml for details. =20 > >>> =20 > >>> Release Notes:https://www.boost.org/users/history/version_1_87_= 0.html > >>> Sponsored by: Future Crew, LLC =20 > >> 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? = =20 > > I don't think that was a good idea either. When broken ports are discov= ered > > 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 prob= lems. > > =20 > >> 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. =20 > > 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. > > > > =20 > >> Maybe give it next time a little more reaction time for the consumers = of > >> this lib? =20 > > Agreed. > > > > Certainly disappointing. > > =20 > >> Gru=C3=9F > >> Matthias > >> > >> --=20 > >> > >> "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 =20 >=20 > Hi, >=20 > As much as breakage is bad I do understand fluffy's decision due to how=20 > we currently handle updates of libraries that touches multiple ports in=20 > tree as it's a very tedious and time consuming effort. Much of it lies=20 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=20 > tree for various reason. I fully recognize the fact that everyone have=20 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=20 > policy (which never got finalized to my knowledge)of it but in the end=20 > of the it causes a lot of hold ups, eats a lot of time and some=20 > compromises needs to be made to make progress. I'm not saying that=20 > bulldozing is the way to go but I would also say cut him some slack=20 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=20 > impossible without turning it into a project that's ongoing for months=20 > and by that time we're very much behind. If you want some historical PRs= =20 > have a look at on the "trying to please everyone" approach: >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261302 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278420 >=20 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D279705 (I'm very clos= e=20 > 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@. >=20 > ...to mention a few. >=20 > To be fair, I think a two week heads up is reasonable (generic timeout)=20 > before pushing it or at least for replies due to how frequent upstream=20 > development is and how much time we can "spare/demand" from various=20 > 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! >=20 > Best regards, >=20 > Daniel --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0