Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

demerphq (2831)

  (email not shown publicly)
http://www.perlm ... l?node_id=108447

Perlmonk. Perl5 Regex Hacker. Telecoms Billing Specialist. Canadian living in Germany.
+ -

  Comment: Re:Straw men lack JFDI (Score 1) on 2009.03.22 8:14

by demerphq on 2009.03.22 8:14 (#67891)
Attached to: There's a reason...

I've been watching how some other projects manage this kind of stuff, and I have a few thoughts.

First, you were doing maint releases, and backporting from dev into maint. I dont think that many projects have high frequency maint releases, in most projects maint releases are instead "just enough for the release to not be a problem" and only made as absolutely necessary. If a project has high frequency releases its at the bleading edge not in maint.

Second, IMO backporting from dev to maint AT ALL only makes sense if dev and maint are relatively in sync. The further ahead dev gets, the more likely that you have to major work to back port a patch.

Now it seems to me that doing regular dev releases is MUCH less of a burden that doing regular maint releases. I would hypothesize as well that regular dev releases would make it eaiser for maint to stay synced themselves. As smaller dev releases would mean more major versions, and more major versions would mean that the bleading edge would tend to be closer in terms of code to its predecessors, which in turn should reduce the back port burden of important fixes.

So I guess while I am not going to argue with you about the burden of our current processes, its not clear to me that it isn't a self fulfilling prophecy. There would be no reason to do heavy work in a maint track if the dev track was moving faster.

Personally Im inclined to think we could accelerate our dev releases a LOT. In fact I think one is long overdue already. Although I know perfectly well how busy Rafael is and that rolling a release right now is probably not something he really wants to do I am somewhat of the opinion that we should make sure that we have all the major platforms passing test for a few days and announce 5.11.1 as soon as we can. And then do our best to announce 5.11.2 soon after. Who cares if that means that we do a LOT of minor releases in the 5.11 line. At some point or another well decide its good enought to go out the door, and we wont be talking about maintaining 5.10 well be talking about maintaining 5.12.

Anyway, I guess my point is that making the caboose more efficient isnt going to make a train faster. Making the engine go faster will. And we /can/ make the engine go much faster in dev if we choose. Pretty much as simply as saying "today is 5.11.1 day". Its a blead release, who cares if it breaks here and there. Thats what they are for.

Would I be correct in thinking that leaving the quality of the latest blead aside that to release 5.11.1 is a matter of creating a tag, rolling and uploading a CPAN bundle and sending out an email?


Read More 23 comments
Comments: 23