[HEADS UP] GNU make 3.82
dougb at FreeBSD.org
Sun Mar 13 02:30:59 UTC 2011
On 03/12/2011 16:00, Ade Lovett wrote:
> On Mar 12, 2011, at 17:22 , b. f. wrote:
>>> On Fri, Mar 11, 2011 at 09:14:50PM -0800, Doug Barton wrote:
>>>> There are way too many things happening "in private" around
>>>> here and the only way to solve that problem is to open the
>>> Would you please offer examples of decisions that you feel that
>>> way about?
>> We need not look any farther than this episode to see an example
>> of how things could have been handled better. I don't think that
>> the course of action that was ultimately adopted was unreasonable,
>> but did we have to wait from the 8 October, when I filed
> I quote from the PR log:
> State-Changed-From-To: open->suspended State-Changed-By: ade
> State-Changed-When: Fri Oct 8 16:40:29 UTC 2010 State-Changed-Why:
> gnu make 3.81 -> 3.82 is, sadly, exceptionally non-trivial. A
> number of features present in releases prior to 3.82 are technically
> "wrong", and this release has corrected them. A _lot_ of stuff
> breaks. It will be looked at, but don't hold your breath.
> Plenty of other stuff was happening in autotools-land at the time.
> We had already run a previous preliminary analysis of gmake
> 3.81->3.82 and it was _not_ pretty.
> That update to the PR took just a little under 2 hours from initial
> submission. Suggesting that it took until March 11th is disingenuous
> at _best_
Taking a mere 2 hours to slap someone down who was trying to help is not
the same thing as actually making useful headway on the problem.
To make matters worse, I finally took the time to figure out when 3.82
was released. I hadn't done so previously because I was afraid to know
the answer. It's worse than I thought:
So either we have an emergency now because the problem has been ignored
for 7 1/2 months, or there is no emergency.
>> to learn what was actually broken by the change, so that we could
>> begin to fix it?
> This requires multiple -exp runs. A number of ports that failed with
> 3.81->3.82 have a non-trivial number of ports that depend on them.
> Simply taking the first set of breakage does _not_ present the entire
> picture. Short term hacks, such as allowing those ports to build
> with 3.81 are _required_ in order to fully understand the depth of
> the situation.
This is only true if the only possible answer you're willing to
entertain is, "those of us who have always done this work will be the
only ones to look at the problem, thank you very much."
It's painfully obvious at this point that what _should_ have happened
when the problem was first discovered is basically what I have been
suggesting all along. Send a message to ports@ and cc the maintainers of
all ports that USE_GMAKE and ask them to test their port with gmake
3.82, and fix it if necessary. If that had been done 7 months ago we'd
be done by now.
> Infrastructure work is a painful experience. Throwing out a PR with
> "exp-run probably desirable" is not particularly useful, and shows a
> certain naivety when it comes to such wide-ranging changes. It is a
> highly iterative procedure, requiring many man- and cpu-hours of
> work. Those of us that do it may not be doing the best possible job,
> but there's a distinct lack of volunteers to actually run the
One could also make the argument that there is a distinct lack of desire
on the part of some who do this work to let anyone else help. For
example, instead of simply saying, "don't hold your breath" what would
have been more helpful are suggestions on how to proceed, what b.f.
could help with, etc.
The real problem here is that there is a very tiny subset of FreeBSD
developers who insist on taking on a disproportionate amount of "behind
the scenes" responsibilities, and are incredibly resistant to allowing
anyone else into the inner circle. It's that attitude that I'm concerned
about, not the details of this specific incident.
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
More information about the freebsd-ports