use Perl

• Straw man (Score:2)

  by autarch (914)

  I don't think chromatic is proposing that Perl start break back compat willy nilly. He's been quite clear that he wants to see Perl on a time-based release cycle with published deprecation schedules.

  Imagine if Perl release 4 times a year. Then if there was a desire to deprecate something, a release could say "feature X will be removed after 6 more releases, 18 months from now".

  That seems pretty reasonable.

  Furthermore, no one out there is jumping from 5.6 to 5.10 without some serious testing. Even with Perl'
  • Straw men lack JFDI (Score:2)

    by nicholas (3034)

    I don't think chromatic is proposing that Perl start break back compat willy nilly. He's been quite clear that he wants to see Perl on a time-based release cycle with published deprecation schedules.

    Imagine if Perl release 4 times a year. Then if there was a desire to deprecate something, a release could say "feature X will be removed after 6 more releases, 18 months from now".

    That seems pretty reasonable.

    I don't disagree with anything you say. Heck, I agree with it.

    But

    I tried it. This is me. I have made m
    • Re: (Score:1)

      by chromatic (983)

      I don't think your list is fair, Nicholas. I (and a few other Parrot developers) have a decent idea what it takes to make regular releases. We have over two years of experience doing just that. Parrot's not in the same stage of its lifecycle as Perl 5, but we've managed to reach a place where releasing a new version is very little fuss, comparatively speaking.

      There was a thread last year on p5p where several people volunteered to perform releases, provided that they could follow a brain-dead easy script
      • Re:Straw men lack JFDI (Score:2)

        by nicholas (3034) <nwc10+useperl@colon.colondot.net> on 2009.02.22 15:02 (#67541) Homepage Journal

        There was a thread last year on p5p where several people volunteered to perform releases, provided that they could follow a brain-dead easy script to put everything in order. To my knowledge, no one who could put together that script took advantage of several willing volunteers. (For goodness' sake, though -- volunteers wrote a perldelta.)

        Ah yes. This was my reply to that [mpe.mpg.de]. Several people, most of whom in their replies quoted my message that precisely what was needed was people who could follow the key part of your (wise) instructions for parrot [mpe.mpg.de]:

        6) Find half a dozen trustworthy people who know enough about the project to work through the checklist in step 2. Their most important skill is the ability to figure out when that checklist doesn't match reality and update the checklist. They need commit privileges. They do not need to be the second coming of Chip.

        i.e. anything but something brain dead easy and scriptable. No-one volunteered to do the hard stuff, particularly those people who had mis-volunteered themselves earlier, which is evident from the replies to that message of mine.

        And, yes, true, that volunteers wrote all of the perldelta. But only about half of the perldelta you see [cpan.org] was from the perldelta project [github.com]. The volunteers there, human like the rest of us, ran out of steam, with some chunks not finished. Schwern [mpe.mpg.de] found a heck of a lot of errors in the module versions. I fixed a heck of a lot of copy editing, wrote the New Tests section [cpan.org] from scratch, and quite a lot of other things that someone else could have done, had someone else existed.

        But in the end, something else you said then rings true: [mpe.mpg.de]

        Volunteers help, but we've discovered in Parrot that putting final responsibility on one person (no more than once or twice a year) is the only reliable way to get something done on time.

        Reply to This

        Parent

        • Re: (Score:1)

          by chromatic (983)

          I agree with all of that, with one caveat:

          Releases aren't that big a deal. There's a new release on the schedule. This one doesn't have to be perfect. It just has to be better than the previous one.

          We could discuss strategies for making releases much easier (getting rid of the blead/stable branches and making all features and integrations take place on git trees, getting smokes of those alternate trees, and pulling only when they're clean), but the first step is "Write down what it takes to make a releas