Front page | perl.perl5.porters |
Postings from September 2011
Re: The future of POSIX in core
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
September 2, 2011 05:57
Subject:
Re: The future of POSIX in core
Message ID:
20110902125723.GX23881@plum.flirble.org
On Fri, Sep 02, 2011 at 01:47:52PM +0200, Mark Overmeer wrote:
> I really get fed-up with this lecture everyone likes to add to emails
> about this subject. This must be at least the tenth time someone tries
> to demotivate me in the past half a year. Perl-core developers are not
I'm not trying to demotivate you. I don't mean to come across that way,
and I'm sorry if I do.
> the only programmers in the World with experience in large projects! And
Agree perl is not unique. But it's not just a large project.
It's a
1) large project with a legacy codebase
2) not all downstream dependent code is visible
this has not been the case with most large employer codebases I've dealt
with. There it is possible to search the entire codebase, and be confident
that one has accounted for all uses of something.
3) no control over the rollout schedule
even in a large employer codebase, it's possible to have a "flag day" and
change every use of something troublesome. Or, to arrange for a sequence
of upgrades that systematically eliminate something, without breakage.
We can't do that for end users of the core distribution.
4) very slow feedback
both in terms of "this core change was a mistake" and, amount of time it
takes to be confident to test a stable release.
5) reputation for not breaking things
better than most of our "trendy" competitors
Combine 3 and a desire to retain 5, and it starts to give different dynamics
on what level of breakage feels acceptable.
Combine 3 and 4 and it makes stable releases nerve wracking. I don't think
that anyone has made a stable release less than 10 days elapsed time from
making a first release candidate. The big fear is that one ships a "stable"
release that is a dud, and before one can make an upgraded release that fixes
this, some operating system downstream has integrated that release and gone
gold with it. Some upgrade, but at least some have never upgraded from the
particular point release they first went with, which means crap code is out
there, propagating, with one's name on it, causing bugs and bug reports.
Whereas my impression was that
a: operating system vendors have been happy to upgrade CPAN modules.
b: there's a big cultural difference seen between "build your own modules"
and "build your own perl", with the result that people are happy to have
*modules* installed or upgraded locally, but keep relying on the
"system perl".
result - system perl is stuck at whatever now-ancient version, good or bad,
that was current-ish at the point of OS release, whereas modules move on.
Hence the steering and shipping the perl core doesn't feel like either a
large work codebase, or a CPAN module.
I suspect that shipping other widely deployed, rarely upgraded,
infrastructure-level code is analogous to shipping core releases.
I think Brian May's quote about his PhD thesis sums up nicely how I felt
about each core release:
http://news.bbc.co.uk/1/hi/6961171.stm
"It's a bit like an album - you've got to live with it for the rest of
your life, so you want it to be perfect,"
for the same reason - once it's out there, you can't change it.
[Note, I have never made an album, and probably never will. But I can say
that it's lot more work getting a PhD thesis ready than a core release]
> even iff I would have no experience, then still some of the points above
> do make sense.
> Let's try to focus on improving perl and study each others contributions
> in detail before judging based on "I see you on IRC"/OSCON/YAPC, or not.
Agree.
Independent of all the other things, fixing the documentation for POSIX
would be really useful.
Nicholas Clark
Thread Previous
|
Thread Next