Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
From: Nicholas Clark
June 24, 2009 03:07
Re: Perl 5.10.1
Message ID: 20090624100650.GS33745@plum.flirble.org
On Wed, Jun 24, 2009 at 11:34:09AM +0200, demerphq wrote:
> 2009/6/24 Rafael Garcia-Suarez <email@example.com>:
> > 2009/6/24 Ovid <firstname.lastname@example.org>:
> >> I want to encourage people to experiment. Perl really, really needs some
> >> help and barring Perl 6 being released and adopted tomorrow, Perl 5 is the
> >> pony to bet on right now. Rafael holds the keys to the main branch of Perl
> >> right now and he's taking a conservative approach, as is his right. Thus, I
> >> don't see anything changing there. We need a good, stable fork where we can
> >> try to make Perl a modern language. Maybe's it's Schwern's fork. Maybe it's
> >> Kurila (I honestly don't know as I haven't paid enough attention).
Has anyone tried Kurilla?
There is git now. Making third party forks is easy. I'm not stopping anyone.
[Perforce never had a problem with merging. It had, and still has, a problem
with anonymous access. Because all state is on the server, each checkout is
contributing to a denial of service.]
> > Seriously, I don't see the point of forking. You'd want to fragment even more
> > the little resources we have for Perl 5 ? If someone sees me as an impediment
> > and wants the patch pumpkin, then ask.
> I dont think you are the impediment. I think the impediment is perldelta.
I think the impediment is a lot of people who say that they want it, but
don't want it enough to reprioritise it above their other wants.
Either by making the time to do it, or by making the time to organise others
to do it.
[And I don't think that you're the problem either, because I know that you're
busy, and frankly if you have time to give to perl, I'd prefer it if you
looked at the regexp bugs in the 5.10.1 triage list at
> If we can fix the perldelta problem then we can rollout more often.
> Fixing the perldelta problem could range from requiring all patches to
> include perldelta notes, to reducing the cost producing it by making
> it contain less info.
Requiring all patches to contain perldelta notes is inappropriate.
For each of the last two nights I've done one seventh of the 5.10.1
perldelta backlog, and the amount of editing needed is ruthless - less than
10% of change entries deserve mention.
Best Practical have been working on a proposed solution to this, which I've
been alpha testing, as part of getting the 5.10.1 backlog done.
[Others not in Best Practical were supposed to be - I don't know what happened
to them, and their chief cat herder seems to be out of contact. I'm not
minded to point fingers until they've had time (and "opportunity") to confess
It's an application to let everyone who wants to help, help by distributing
the work of filtering the change log. It lets people tag commits as to the
section of the perldelta they go into. It then sorts the commits by section
[which is more useful than committer, because git doesn't know when committer
A amends or reverts a change or sequence of changes that committer(s) B (and C)
and produces a draft perldelta. Extremely draft, but actually quite useful.
Currently I've been going through it section by section, but actually that
part could be parallelised too. (Although I hope to have it done in 5 or 6
days, which is likely faster than trying to train and outsource it *this*
In turn, I then expect to be able to write perl5111delta by taking
perl5101delta and merely adding in bits relevant to changes not merged.
Which was why I was asking what the best way to create that change "log"
If we can get that change log in the standard git format, we can feed it
into the tool. Otherwise, we'll have to improvise this time.