Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from June 2009

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 30, 2009 09:36

Subject:

Re: Perl 5.10.1

Message ID:

20090630163556.GF33745@plum.flirble.org

On Wed, Jun 24, 2009 at 09:19:18AM -0700, David E. Wheeler wrote:
> On Jun 24, 2009, at 2:34 AM, Nicholas Clark wrote:
> 
> >On Tue, Jun 23, 2009 at 07:27:40PM -0700, David E. Wheeler wrote:
> >
> >>That leaves out those of us who detest packaging systems, and hate
> >>having to maintain scripts that apply patches, constantly having to
> >>decide what patches we need and what we don't for production.
> >
> >But you are not in the majority.
> 
> And as you pointed out in your use Perl post, it seems that users of  
> RHEL in particular suffer because they're not in my minority.
> 
> OTOH, if we had more frequent stable releases, I should think that  
> this problem would be reduced. I miss the days you were doing a  
> release every quarter!

I miss the result. I don't miss the work involved. I remember that Richard
Clamp predicted in advance that I'd burn out, and he was right. (When he
chooses to express an opinion on something, he's invariably correct)

Specifically, it ended up with making releases for my own enjoyment
(effectively) because we weren't using them at work, and there wasn't
any real push other than "this feels useful, and I'd said I'd do it"
And it became easier and easier to stop being up-to-date on merging from
blead, because the fun wears off after a while, and it starts feeling like
and obligation and hence work.

Which isn't sustainable as a hobby.

I'm coming to the view

a: That quarterly may not be the best way actually. Too few early releases,
   too many later releases.

   What I'm thinking might be best is having planned interval*s* to code
   freezes for the maintenance branch. This is assuming that all bug fixes get
   into blead by someone-not-the-maint-pumpking, as has roughly been happening
   since 2003. Merging (cherry-picking) is assumed to run in parallel, with
   a minor lag to assess stability in blead. (Or whichever branch is
   the integration and "please CPAN smoke this")

   So, 1 month after 5.14.0 is shipped is the cutoff to get fixes into blead
   for 5.14.1-RC1. 2 months after 5.14.1 ships is the cutoff to get fixes
   into blead for 5.14.2-RC2 etc.

   This would mean releases at 1, 2, 3, 4, 5 and 6 months (then steady state
   at 6 months, or possibly even go to "build fixes and security issues only),
   which is 6 releases across 21 months, rather than 7 quarterly, but with
   releases concentrated where it matters more.

b: This is a job, not a hobby. This is providing a support service, and I
   don't think that it's viable to do this for free.

   But the fact that I don't see anyone already making a business out of it
   that is feeding patches back to us suggests that it's not easy to part
   firms with their money for this. Certainly the commercial OS vendors
   don't behave in this way. [Debian isn't a commercial OS vendor]

Note, that while I'd like 'a' and 'b' to exist, I don't have a means to make
them happen. I'm not made of money, or time, and I don't have a cult of
minions who will spring to any task that I suggest is viable.
(Whether it is viable or not)

Whilst TPF exists, it too is made of volunteers, and I'm assuming that
they're not going to be the white knight riding to deliver salvation
by making something like this happen.

> But that's a problem no matter what you do. If I upgraded from 5.8.8  
> to 5.8.9 in a production system now, and everything seemed to work  
> well, and it was only a month after it went to production that we  
> discovered subtle bugs, how long would I need to wait for 5.8.10  
> before it could be fixed?

General answer: Guaranteed fix - never. You're getting what you pay for.
(Comment above about business versus hobby)

Specific 5.8.10 answer - shrug - it depends. My release notes for 5.8.9 said
that maint-5.8 is likely only to have security and build fixes from now on.
"It depends" is because if someone volunteers to do more than that, then more
than that will happen. But it's not me doing it.

But even with a scheduled release policy, there's no guarantee that

a: the bug would be fixed in the next release
b: that the next release would happen on schedule

so it's a delusion to assume that a release schedule will actually cause
reported bugs to become fixed.

[I don't think that you were implying this, but I think I should make it
clear in case anyone misreads it, the way I did at first]

> Look, I'm not trying to be snarky here, and I'm clearly a P5P newcomer  
> (though an oldcomer with Perl itself!). So maybe I'm just dead wrong.  

You're not wrong. And I've never noticed you being snarky on other lists
online, so I assumed that you weren't.

> It's entirely possible (my wife will tell you it's frequent). However,  
> I have not been convinced by the discussion so far. AFAICT, more  
> frequent stable releases will better address the points you've raised  
> than infrequent stable releases.

Generally yes, I agree.
The devil is in the details, and how we get from here to there.

Nicholas Clark

Thread Previous | Thread Next