Re: Perl 5.10.1

Front page | perl.perl5.porters | Postings from June 2009

Thread Previous | Thread Next

From:

Nicholas Clark

Date:

June 30, 2009 08:18

Subject:

Re: Perl 5.10.1

Message ID:

20090630151808.GD33745@plum.flirble.org

On Wed, Jun 24, 2009 at 10:39:09AM -0400, David Golden wrote:
> 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.

Which is why you see me and Dave getting grumpy when it turns out that
changes are committed direct to blead that should be punted upstream.

Which is why I'm trying to get everything possible moved from lib/ to ext/
so that it's obvious what's core and what needs to be treated as dual.

And why I patched perlbug so that it would try to identify an upstream
bug tracker based on the module, to try to send bugs direct.

But we *are* stable, by one definition, because blead passes its tests.

Which is what I meant by "works on my machine". I can make test before a
commit, but on that machine only. I *can't* test on other machines. I
could conceivably run a smoke of CPAN, but the estimate is that that takes
a week. Hence why I don't think that issuing a fiat that there will be a
formal cultural change is going to achieve anything in itself.

I don't object to the end results you wish to achieve, because actually
they're the end results that I'd like to see to. But I think that the
way to get there is identifying and implementing incremental changes needed
to get from where we are now to where we want to be. Which, to my mind,
means people prepared to get their hands dirty helping, and working with
the people already doing things, rather than writing lots of e-mail
without contributing time or code.

[And, as usual, if anyone thinks that this is a personal attack, think
again. David Golden is working bloody hard on Module::Build, and I'm sure
that if anyone would like to help get things done, but the core doesn't
appeal, I know that he'd welcome help there:
http://www.dagolden.com/index.php/255/modulebuild-bug-triage-help-requested/
]

> Let's make stability the norm and instability the exception, not the
> other way around.

There has to be an integration branch somewhere. I can't see how to get away
from that.

maint-* is already trying to keep stability as the norm, and, I think,
usually roughly there.

So, I feel, what already happens is closer than might be apparent from parts
of this discussion so far.

And, in the end, my suspicion is that the biggest blocker on the core (and,
for all I know, Module::Build and any other major project), is that the
amount of third party contribution is not that great, resulting in the core
volunteers having to do a lot of the "this must be done" unfun work
themselves.

Nicholas Clark

Thread Previous | Thread Next