can we merge…

In PSC #60 notes, I wrote:
> The question of "can we merge created_as_X at this late date" was discussed.  Rik will post more about this, but the general consensus was, "Yes, and generally we think late additions are okay if we feel very confident they will not break existing programs."  We'll be looking at adding some language about this to the release schedule.

I have really been putting this off.  Or, rather, I have been letting many other things come first.  On the whole, I think I made the right choice, but I am also sorry it's taken so long to get here!

First:  Look, I think we can put created_as_X into blead.  I think it's safe, it won't break existing programs, and if it has problems, we'll fix it in 5.37.  Experimental features can be partly-baked as long as they don't break programs that don't turn them on.

This is the basic position I want to advocate for.

We have a code freeze where, over the course of a few months, we go from "blead is a bit of a mess of a work in progress" to "we could release blead and it would not be a total catastrophe" and finally to "this is ready to be the next release and it will be great."  Different porters have a different level of enthusiasm about the freeze in general and about the various transitions of one phase to another.  That's normal, because we porters are all distinct humans.  I don't subscribe to "if both sides don't like it, it's a good compromise," but I think that in this case, we do strike a balance where there isn't, and won't be, universal acclaim of the position we take.

The position I take is this:  as we approach the release date, we should be landing features and fixing bugs.  The features we land should not introduce bugs in programs that don't use them.  That's roughly it!

Our new features tend to be marked experimental.  "Experimental" doesn't mean "there might be bugs," but in new features, it's conveniently correlated.  When we add new experimental features, we really hope that they're right.  If they are, they can become stable features of Perl even sooner!  But if they're not, we've expressly disclaimed any stability guarantee.  They can be very broken, they can change behavior, they can be dropped.  They're still evolving.

If we can merge them without introducing instability to other parts of the system, I think it should be fair game.  Now, we can't always feel confident that we can do so!  If the experimental feature works by changing (say) the structure of every SV, we're taking a huge risk!  On the other hand, if all of its behavior is gated by the feature flag, we're probably safe.  Some features will be partway between, and we should be circumspect.

What I am interested in is a perl that is, first, *no worse* than the previous perl, but next, *also better* than the previous perl.  Sometimes, this means that we need intermediate steps where we've added partially-baked features for the sake of finding out which bits of them are raw.

Now!  The question that might get raised is about whether we have time for this sort of thing.  "Look," one might say, "the next release is in two months.  We should be spending our time on quality control rather than landing new semi-complete code!"  I think this is an incorrect view of the process.  Those people who perform quality control and bug fixing are rarely the same people who are polishing new features.  By denying the feature-writers the ability to ship the experimental feature, we don't actually gain their time for quality control.  We only reduce their enthusiasm for working on new features.  All this, of course, is mediated by the question of whether the experimental feature will destabilize the rest of perl!  If so, it's definitely out of bounds.

I have not sent this email to my compatriots on the PSC, so they may not agree with the opinion I have put forth, and I hope they will reply to say whether they do or don't.  I think these sorts of opinions are useful to understand what kind of process the PSC is steering toward.  I just want to be transparent about how I view this.

-- 
rjbs

• can we merge… by Ricardo Signes
• Re: can we merge… by demerphq
• Re: can we merge… by Yuki Kimoto
• Re: can we merge… by Paul "LeoNerd" Evans
• Re: can we merge… by "G.W. Haywood" via perl5-porters
• Re: can we merge? by Oodler 577 via perl5-porters
• Re: can we merge… by Paul "LeoNerd" Evans
• Re: can we merge… by Ricardo Signes