Mailing List Archive

On Mon, Mar 13, 2023, at 02:21, Renée Bäcker wrote:
> in https://github.com/Perl/perl5/blob/blead/Porting/release_schedule.pod
> no release managers are assigned to the next development releases.
>
> Do we have a list of the release managers? The next release should be
> published next week...

From the PSC call today, my understanding was that Yves would be making a release next week, possibly a day or two later than the 20th.

We do not yet have an April releaser. Volunteers welcome. ????

--
rjbs

Am 18.03.23 um 02:04 schrieb Ricardo Signes:
> On Mon, Mar 13, 2023, at 02:21, Renée Bäcker wrote:
>> in https://github.com/Perl/perl5/blob/blead/Porting/release_schedule.pod
>> no release managers are assigned to the next development releases.
>>
>> Do we have a list of the release managers? The next release should be
>> published next week...
> From the PSC call today, my understanding was that Yves would be making a release next week, possibly a day or two later than the 20th.
>
> We do not yet have an April releaser. Volunteers welcome. ????
>
If April 24th would be ok, I can do the April release.

- Renée

On Sat, 18 Mar 2023 at 02:05, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Mon, Mar 13, 2023, at 02:21, Renée Bäcker wrote:
>
> in https://github.com/Perl/perl5/blob/blead/Porting/release_schedule.pod
> no release managers are assigned to the next development releases.
>
> Do we have a list of the release managers? The next release should be
> published next week...
>
>
> From the PSC call today, my understanding was that Yves would be making a
> release next week, possibly a day or two later than the 20th.
>

It should be the 20th as scheduled. I just said I wouldn't be available on
the 19th. The 20th I am free to pick this up. It /might/ take me a couple
of days as I havent done it before, but I listened in when Max did it
recently, and I think I should be able to get it done in a day. :-)

cheers,
Yves

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

On Sat, Mar 18, 2023, at 06:38, demerphq wrote:
> It should be the 20th as scheduled. I just said I wouldn't be available on the 19th. The 20th I am free to pick this up. It /might/ take me a couple of days as I havent done it before, but I listened in when Max did it recently, and I think I should be able to get it done in a day. :-)

Thanks, I'm sure I just misunderstood, then.

I also think you should have no trouble doing it in a day.

--
rjbs

On Sat, 18 Mar 2023 at 16:57, Ricardo Signes <perl.p5p@rjbs.manxome.org>
wrote:

> On Sat, Mar 18, 2023, at 06:38, demerphq wrote:
>
> It should be the 20th as scheduled. I just said I wouldn't be available on
> the 19th. The 20th I am free to pick this up. It /might/ take me a couple
> of days as I havent done it before, but I listened in when Max did it
> recently, and I think I should be able to get it done in a day. :-)
>
>
> Thanks, I'm sure I just misunderstood, then.
>

Turned out to be prophetic tho. :-) I forgot to ask Andreas for PAUSE
permission to do the upload. So the rest will have to happen tomorrow.

Folks that are interested can test the RC1 with:

https://www.dropbox.com/s/rhzvaf9jni9btwu/perl-5.37.10-RC1.tar.gz?dl=0&raw=1
https://www.dropbox.com/s/9mrxxblv9xhkgu7/perl-5.37.10-RC1.tar.xz?dl=0&raw=1

Doesn't look like a RC2 is required.

Sorry for the delay. I dont think I'll change the release date in
perlhist unless someone replies to say I should.

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.

cheers,
Yves

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

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.
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, and
the rest is jumping around in the RMG looking for references to
Module-CoreList because the positioning is all wrong for blead releases,
for a total of about 4-6 hours (much of which can be done in advance of the
day).

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/"