Front page | perl.perl5.porters |
Postings from March 2023
Re: Who is going to do the next releases?
Thread Previous
From:
demerphq
Date:
March 23, 2023 11:22
Subject:
Re: Who is going to do the next releases?
Message ID:
CANgJU+WhqxvaMtq_+PkV1f83oZ_OyweoikL4HV0YHQMD90Q5pA@mail.gmail.com
On Thu, 23 Mar 2023 at 03:20, Karen Etheridge <perl@froods.org> wrote:
>
> On Mon, Mar 20, 2023 at 3:55â¯PM demerphq <demerphq@gmail.com> 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"
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous