develooper Front page | perl.perl5.porters | Postings from August 2011

Claim: criteria for patch to be considered for dot release is bugwas introduced in current series, not necessarily regression

Thread Next
From:
Karl Williamson
Date:
August 12, 2011 10:19
Subject:
Claim: criteria for patch to be considered for dot release is bugwas introduced in current series, not necessarily regression
Message ID:
4E45607C.2050706@khwilliamson.com
We've gone around on this issue before, and I don't believe we've 
settled it.  So I'm trying again, this time I believe I have more clarity.

I believe that a patch should be deemed considerable for a dot release 
if it fixes a bug that was introduced somewhere in its major release 
cycle.  So, something that was broken in 5.14.0 should be fixable in 
5.14.1, 5.14.2, etc.

The effective difference between this wording and the current one is 
that it allows bugs in new features to be fixed without having to wait 
until the next even-numbered release.

There was some bemoaning on this list a while back that we don't seem to 
get people using new features much until a major release or two after 
they first appear, and the original developers have moved on to 
something else, and aren't available to fix things.  I maintain that our 
current policy promotes this hesitation to try things out, because the 
conventional wisdom is to avoid a .0 release of any product, and our 
policy effectively means that the whole major series is a .0 release for 
new features.

If there is a new feature that is going to make my life better, but I 
know that it is a .0 release, and that it's going to be a year before 
any bugs in it will be fixed, I'm going to be leery of using it.  I'd be 
willing to experiment more if there's a release scheduled a month or 
three away.

I claim that the current policy is shooting ourselves in the foot.  It 
encourages lower quality by discouraging usage of new features in the 
field, with the consequent effect that the developers who made them 
think the quality is higher than it is, and they get bored and move to 
something else, and even if they are available years down the road, have 
forgotten a lot about the implementation.

It shouts out, "We don't service what we build, at least not for a long 
long time."

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About