develooper Front page | perl.perl5.porters | Postings from March 2023

Re: Who is going to do the next releases?

Thread Previous
March 23, 2023 11:22
Re: Who is going to do the next releases?
Message ID:
On Thu, 23 Mar 2023 at 03:20, Karen Etheridge <> wrote:
> On Mon, Mar 20, 2023 at 3:55 PM demerphq <> wrote:
>> There is an awful lot of manual stuff in that process that IMO could be automated, and at least some that I wonder if it really is necessary (comparing the files from one release to another for instance, isnt that what the MANIFEST is for?). Definitely a todo list where experience would make a difference in how long it takes.
> I don't do that. I also skip most of the places in the RMG that have you doing a git -dxf; ./Configure ...; make test and save that for the end.

Nod. Being my first time, i tried to stick to the script, but I think
next time I would do the same.

> 80% of the time I spend is reviewing every commit (on average there are about 200 of them between releases) for sanity and the possible need for a perldelta, 10% of the time is spent editing the perldelta file itself,

Nod. I agree, much of the time I spent was related to the perldelta.

> and the rest is jumping around in the RMG looking for references to Module-CoreList because the positioning is all wrong for blead releases,

Yes. The whole Module-CoreList thing is unfortunate in lots of ways:
it lives in dist, even though it needs to be synced back from cpan (I
patched sync-with-cpan to make it possible to backsync a dist module,
you can use the --type=dist option [undocumented as yet, but ill fix
that]), and then the automated update script doesn't know how to find
out the correct release date. It is all kinda bodged.

> for a total of about 4-6 hours (much of which can be done in advance of the day).

That is less time than I took, but i let myself get distracted with
p5p questions at the same time, and I tried to execute every step more
or less faithfully.

Good thing we only do this every month or this time commitment would
be really out of hand. As it is I think it could do some love.

Some thoughts:

1. Figure out a way to produce a single "rmg guide" file (from
templates I guess) which contains *only* the instructions for the type
of release you are doing.
2. Separate "pre-release steps" into a separate document.
3. Automating as many of the steps as possible with scripts.
4. Using a template to create the guide in such a way that the
template can properly distinguish "previous version"/"next version"


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About