"David Golden via RT" <bug-Module-Build@rt.cpan.org> writes:
Show quoted text> My view is that if M::B hard-coded a value, then it is accepting
> responsibility for getting it right. When I was maintainer, I didn't
> want that responsibility.
Fair enough, but you're just trading different kinds of
responsibilities. The responsibility to not introduce new bugs and the
responsibility to not decrease the resilience and the reliabilty of the
CPAN as a whole are just two of the responsibilities you cannot really
escape when you release something.
Show quoted text> Therefore, M::B follows a "fail safe"
> principle, which is that if the author doesn't specify something (or
> turn off auto config requires), then the prereq is the version they
> are using to ship because that is the only one known to work.
I'm not so sure that you know it to work. All you know is that this
(current) Module::Build was able to generate that (current) release of
distro X. You do not know whether it will work for installing on the end
user machine. You do not know, say, whether this release will eat files
on the end user machine. You do not know it for the previous version
either, but if you allow the previous version, there is a chance that
the enduser will find out. Or by virtue of statistical evidence there
will be a finding on cpantesters that tells you something about which
bug is at work.
Show quoted text> Anything else is a guess, which is eventually going to be wrong.
Sure, where there is development there are bugs. The bug I'm reporting
is just one of many, but it is a meta bug, and that is why I'm so
serious about it.
"Eric Wilhelm via RT" <bug-Module-Build@rt.cpan.org> writes:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=58445 >
>
> # from (Andreas J. Koenig) via RT on Tuesday 11 September 2012:
>>> The default is designed to do something simple and stupid and
>>> sufficient for most users in the face of lazy authors who don't
>>> declare their own requirements.
>>
>>"Something simple and stupid" sounds like a good characterization,
>>excuse me for picking that up.
>>
>>If one would code '0.40' there statically, nothing would change
>>compared to status quo. And bumping that only once you know that
>>'0.41' has had time to propagate and be widely deployed would solve
>>my gripe. It would be a tiny bit less simple and huge amount less
>>stupid.
>
> The "simple and stupid" thing is going to be more dependable than this
> clever bug. If *anything* changed from 0.40 to 0.41, then you have a
> chance of users getting caught without a working installer because of
> this optimization -- regardless of how "widely-deployed" it is.
If *anything* changed, then there is a chance of users being caught with
a freshly introduced bug.
Show quoted text> Repeat that risk on every new release of M::B.
>
> Is the time saved in upgrading M::B really that large?
It depends. Time that can be shifted is in general not hurting as much
as time that must be spent here and now. Multiply that time by the
number of sysadmins that will be affected.
Show quoted text> How often is
> there a new version which doesn't fix some bug or add a feature on the
> installation side? I think the maintenance load and the risk of bugs is
> not worth the savings (whatever that savings is... if upgrading takes
> too long, let's fix that instead.)
Show quoted text>>> If a version of
>>> M::B gets out with an incorrect default, there is a chance that it
>>> remains unfixed while being used to roll dists, thus requiring
>>> those authors to upgrade and reship just to fix M::B's error (and
>>> finding out the hard way that their dist is not installable because
>>> of it.)
>>
>>...we should estimate that there are
>>significant more end users than there are authors. If there is really
>>a trade-off between burdon for end users and burden for authors, then
>>we should most often shift this burden on the author.
>
> The end users still lose here waiting days for the author to fix the bug
> introduced by M::B attempting to save a few bits and tics.
>
> I know it's saying "upgrade, upgrade", but really: how viable is it to
> *not* upgrade M::B if authors (whose recently released modules are being
> installed) are actively upgrading it and possibly using new features?
> You're not getting configure_requires for a M::B which came out *after*
> the module being installed, right? With all of this change, how long
> will it take for a statically-coded value to cause a bug?
How long it will take? Longer than in your preferred model.
The mathematical argument is easy. There are two versions of
Module::Build, v1 and v2. We all know that both have bugs. You may be
sure that the new version has less bugs than the old version. Fine. But
no doubt the two versions will have a different set of bugs.
Given p1 is the probability to be hit by a bug in v1 and p2 is the
probability to be hit by a bug in v2. The user who is locked into only
having access to v2, is a victim of a bug with probability p2.
Users who have a choice between v1 and v2, have a workaround. If they
are hit by a bug in v1, they can still try v2. They are victims of a bug
only with the probability p3. How big is p3?
If the set of bugs is completely independent of each other, the
probability is p1*p2 which is considerably less than p2. If there is a
common set of bugs it is still less than p2. And only if the bugs in v2
are a subset of the bugs in v1, then p3 equals p2. In all other cases it
is lower.
In other words, p3 is lower in the general case, and it is only in the
worst case equal to p2.
"Ken Williams via RT" <bug-Module-Build@rt.cpan.org> writes:
Show quoted text> <URL:
https://rt.cpan.org/Ticket/Display.html?id=58445 >
>
> On Wed, Sep 12, 2012 at 1:38 AM, (Andreas J. Koenig) via RT <
> bug-Module-Build@rt.cpan.org> wrote:
>
>>
>> If one would code '0.40' there statically, nothing would change compared
>> to status quo. And bumping that only once you know that '0.41' has had
>> time to propagate and be widely deployed would solve my gripe. It would
>> be a tiny bit less simple and huge amount less stupid.
>>
>
> Suppose we did that, imagine the breakage scenario. Suppose the author
> installs 0.42 or 0.43, and we don't think they've propagated very far, so
> the hard-coded value is still 0.40. Then if the author uses *any* features
> that were added after 0.40, or exercises any code that was buggy in 0.40
> but fixed later, then this just BLOWS UP or WORKS WRONG on the end user's
> machine.
>
> So the author, if he/she wants to be a responsible person and not risk
> blowups, has to 1) go check what the hard-coded value is, and 2) figure out
> what all these feature & bug changes are relative to their installed
> version, and 3) not use them. So there was no point in upgrading in the
> first place. So they should never upgrade. So we can never add new
> features. So the project is essentially dead.
Setting up my wishful thinking hat, of course it would be wonderful if
Module::Build could determine which features this (current) author is
using and which features were fixed when exactly and determine the
optimal version that this current distro should put into
configure_requires. I don't expect that this will happen. That's why
David suggests KISS which I agree with in principle. But I doubt his
KISS is the right one. I for one prefer a choice for the end user.
Locking them into a single version or making the choice for them hard
needs deep justification in the very concrete case. If there is a huge
and serious bug being fixed, I would agree that it makes sense to set
configure_requires to the current version. But in the absence of
overwhelming evidence it does no good to prevent choice.
--
andreas
