Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
Thread Previous
|
Thread Next
From:
David Golden
Date:
June 24, 2009 07:39
Subject:
Re: Perl 5.10.1
Message ID:
5d4beb40906240739u311a01c8w180e904e623cb79f@mail.gmail.com
On Wed, Jun 24, 2009 at 10:20 AM, Nicholas Clark<nick@ccl4.org> wrote:
>> And I don't buy the argument that cross-cutting dev work can't happen
>> on branches -- trunk/master is just a branch, after all. If it can
>> happen there, it can happen on a branch.
>
> To make this fly, please help work on figuring out and implementing automatic
> smoking of a configurable subset of branches. The smoking doesn't need to be
> for all configuration permutations, as most blead smokers currently do.
It's in my queue of projects, right after a robust M::B in 5.10.1 and
CPAN Testers 2.0 and arbitrary automated CPAN regression testing for
any distribution. I wrote CPAN::Reporter::Smoker for "turnkey" CPAN
testing. I would love to see the same thing for regression testing and
then perl testing.
But I don't think automated smoking of a configurable subset is
entirely necessary. It helps, yes, but I think a cultural shift needs
to happen first.
> Things won't be stable unless they've already been validated on various
> "obscure" platforms. (And for the purposes of smoking, right now even
> Win32 is obscure, in that only one smoker instance smokes it, and it's full
> time on it.) Without this, they'll "work on my machine" on their branch,
> but pain will only be found once they are merged to trunk, which defeats
> the intent of your plan.
But is it really any worse than today in terms of the end result?
Today everything gets merged willy-nilly and no one knows if things
are really stable or not. There's no responsibility for stability --
it's commit and pray and then the pumpking pays for it.
If a merge proves bad, rip it right back out, chastise the author and
make them provide more evidence of stability in the future before
accepting their merges.
Let's make stability the norm and instability the exception, not the
other way around.
-- David
Thread Previous
|
Thread Next