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 06:25
Subject:
Re: Perl 5.10.1
Message ID:
5d4beb40906240624i5104dd5ue45f165a7c8d7dc8@mail.gmail.com
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.
One problem as I see it with the concern about stability under model
(a) is that there are no known stable way-points from the last
release. Thus, it's a huge effort each time. Plus, there is bug-fix
work constantly merging with new features or new optimization work, so
the potential new bugs are intermingled with the bug fixes.
> I consider creating new bugs, *that people then have to work round anyway*
> to be a greater sin than fixing existing bugs *that people are already working
> round*. I see the former as creating more work, given the assumption that
> people rarely upgrade.
>
> And yes, I do care about people who rarely upgrade. I don't want to cut them
> off, because they don't have to choose to use Perl, and if we make it harder
> for them, the next time they upgrade they may choose something else.
There's a logical contradiction in here. People who upgrade rarely
won't be affected by more frequent releases because they upgrade
rarely. Yes, if they happen to hit a particularly flaky release,
they'll be stuck with it, but they also have a lower chance of
upgrading at the time of a flaky release. (This assumes releases are
only occasionally flaky.)
It's my opinion that the Perl development process is optimizing for
the wrong set of customers. It's optimizing for those for who don't
care about the latest in Perl and having up to date features and bug
fixes, rather than those that do. The most passionate customers --
the ones best able to get the most out of Perl -- are the worst
served.
-- David
Thread Previous
|
Thread Next