All the Perl that's Practical to Extract and Report

Navigation

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Without JavaScript enabled, you might want to
use the classic discussion system instead. If you login, you can remember this preference.

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

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.)

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.

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