Front page | perl.perl5.porters |
Postings from June 2009
Re: Perl 5.10.1
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
June 24, 2009 07:21
Subject:
Re: Perl 5.10.1
Message ID:
20090624142057.GU33745@plum.flirble.org
On Wed, Jun 24, 2009 at 09:24:24AM -0400, David Golden wrote:
> On Wed, Jun 24, 2009 at 6:13 AM, Nicholas Clark<nick@ccl4.org> wrote:
> > I don't like regressions, full stop.
>
> So, once again, we come back to stability. And there we differ on
> means, not ends. I believe it will be easier to be confident in
> stability if the development model changes along the lines that
> Aristotle describes in his response to this thread (and that others
> have before).
>
> Dev model (a): blead trunk usually unstable, pulled into a stable
> state for a release infrequently; maint trunk possibly unstable,
> pulled into a stable state for a release from time to time
>
> Dev model (b): both trunks stable, work happens on branches, onus is
> on branches to demonstrate stability before being merged to trunks
>
> 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.
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.
For example, I remember the pain of trying to get Storable to pass on
all platforms, when it was added to core. That's a module that was already
on CPAN, and (notionally) widely tested, yet had issues with various
exacting platforms. The way I'd see it being done today, under your model,
would be in a branch, which would become merged to core once it was stable.
Hence without preliminary smoke testing of branches, we would not have had
a stable merge.
Again, we had portability issues more recently, when writing shell scripts
to grab the git state and feed it into the right places to show up in -v
and -V output. [The eventual solution to which was "use perl" :-)]
I don't believe that having manually initiated branch smoking is going to
scale here, if I understand the intent of your plan. There would be lots
of branches, and the prime mover(s) of each would end up needing to pester
the poor humans who owned the obscurer machines to "just do this please".
Whereas if it is automated, it won't be a problem or a bottleneck.
Nicholas Clark
Thread Previous
|
Thread Next