Date: Sun, 10 Apr 2022 20:31:41 +0000 From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: [Bug 262940] textproc/libxml2 and textproc/py-libxml2: Revert back to GNU Autotools due to some curl dependencies? Message-ID: <bug-262940-39348-FGBByiX2aJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-262940-39348@https.bugs.freebsd.org/bugzilla/> References: <bug-262940-39348@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D262940 Charlie Li <vishwin@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #23 from Charlie Li <vishwin@freebsd.org> --- Thank you and apologies to everyone who had to suffer from this fallout. Let this be a cautionary tale in many ways. exp-runs will not catch everything. Continuous integration testing will not catch everything. There is no substitute to eating your own dog food, especially when considering non-default OPTIONS. As a fortune(6) from anoth= er Unix-like system says, "Real Users find the one combination of bizarre input values that shuts down the system for days." When much of the open source software ecosystem writes with, tests on and r= uns on primarily Linux in mind, we do not have the luxury of having a baseline assumption that what seems like a simple update or change will be certain to work. While this saga had little to do with chasing down Linuxisms, it does highl= ight how changes that may not seem like a big deal end up as a big deal. And especially for something that has as many consumers as this one here, one m= ust thoroughly justify the merits of proposed changes and back them up through dogfooding. poudriere-testport(8), exp-runs, CI are not enough. These vigilance measures may result in slowing down updates. I too would li= ke to update things in a more timely manner. But we have to strike a balance between that and making sure we can, to the best of our abilities, ensure at least a baseline of "the software works as intended", even with "bizarre in= put values". One user's bizarre is another user's normal. Last, I personally do not prefer autotools. But this is not about me or any other individual preferences; this is about the ecosystem and the correct tooling for the situation. When it comes to this port, CMake may have clean= ed up certain areas, but it caused a wake of mass destruction elsewhere. Detai= ls matter. Everything matters. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-262940-39348-FGBByiX2aJ>