Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
June 24, 2009 03:04
Re: Perl 5.10.1
Message ID: firstname.lastname@example.org
2009/6/24 David Golden <email@example.com>:
> On Wed, Jun 24, 2009 at 5:34 AM, demerphq<firstname.lastname@example.org> wrote:
>> I dont think you are the impediment. I think the impediment is perldelta.
>> 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.
> It's not perldelta, it's the stability standards. We've had that argument.
Regardless as to whether this argument already occured I personally DO
think it is in a big part the actual writing of the perldelta.
We consider stability standards when we apply patches, so we already
put more effort into THAT aspect than we do in making sure that
perldelta is updated with what we have changed. Thus i think the main
problem is writing the perldelta. Its not easy to reverse engineer the
perldelta remarks from the commits that have been applied.
Even if you want to release early, and we dont change our perldelta
policy in some way, you will end up having to write the perldelta just
before the release, which will take non trivial time, meanwhile new
interesting bugs are found, and presto it is decided we should wait
longer for just one more bug fix, and then you are back to writing the
perldelta again. Repeat indefinitely.
> I might say that the problem is the magnitude of delta-perl, which is
> one of the things that causes so much concern over stability. Shorter
> release cycles means smaller scope of changes, which means lower risk
> and more confidence.
Yes, it does make writing the perldelta psychologicially easier, as
one has less haystacks to search. I dont know if actually changes much
overall for reasons i stated above.
perl -Mre=debug -e "/just|another|perl|hacker/"