Perl 5 maintenance, like Perl 5 development, is entirely volunteer based. It relies on people donating their time and labour for free, with the only payback being the satisfaction of getting something done. Unsurprisingly people spend their own free time working on things that interest them. I'm fortunate to be in full time employment, but this has the side effect of drastically reducing the copious free time I have available to work on Perl and other projects. And if instead I have the CFT, where do I find the money to buy coffee?
People ask when there will be a perl 5.6.2 release, a bugfix update in the 5.6.x series. The work required to get any release out of the door is large, time consuming, and generally less rewarding than almost anything else. To the best of my knowledge no-one currently has the spare time or motivation to commit to the task of delivering 5.6.2. Yes, that no-one includes me, but it also includes you; everyone reading this. If you want it, are you volunteering?
Maybe you feel that the "Perl community" (whatever that might mean) should be doing it. But the "Perl community" doesn't get things done, volunteers within it do things, and so far, all the fine words have failed to find a volunteer to do the job. Maybe one will never be found, and the question should not be when, but whether there will be a 5.6.2 release. Do you think that "never" is unacceptable because it makes Perl look bad? Do you think that "never" is unacceptable because your firm is sticking on, or stuck with, 5.6.1 for the foreseeable future? If there is no-one willing to do the job for free, maybe the the Perl community needs to pay someone to do it. We have the organisation to channel money to projects we like, and we have the people who could do it - several core perl developers are un- or under-employed.
If we really want 5.6.2, maybe we should be asking TPF to help sponsor Perl 5 maintenence?
-Dom
Re:Why?
acme on 2003-05-01T14:34:02
There may be bugs, but slightly more import for me are the compilation issues.Re:Why?
inkdroid on 2003-05-01T15:37:08
I guess I'm confused why development on 5.6.X would continue after the release of 5.8.X... Isn't development always done on the latest stable release? Apart from Schwern's genius of course. Re:Why?
Dom2 on 2003-05-01T16:46:05
It's true that most new development is done on the newer versions, but nonetheless, it's important to fix bugs in the old releases and support them.I was just curious as to what needed to be fixed in 5.6.1...
-Dom
Re:Why?
nicholas on 2003-05-01T19:54:54
what needed to be fixed in 5.6.1...Well it plain doesn't compile with gcc 3.1. I think that we should fix that for starters
The patch needed is smalle, and a work around is trivial:
perl -ni~ -we 'print unless/: </' x2p/makefile makefile Likewise 5.005_03 doesn't compile on FreeBSD, unless you know to
Configureit with-Uusenm -Dlddlflags='-shared -L/usr/local/lib' -Dldflags='-Wl,-E -L/usr/local/lib'The knowledge exists - what we seem to be bad at is transferring it into releases on CPAN. And while we fail to do that effectively, people suffer needlessly, and Perl gets a bad reputation.
Re:Why?
inkdroid on 2003-05-01T20:11:37
I still don't really understand why effort should be spent bugfixing perl 5.6.* when stable is 5.8.0... Shouldn't people be encouraged to upgrade to 5.8.0 instead of waiting for a newer 5.6.*? I guess this is something I'm not grokking about the Perl development process. If volunteer time is short shouldn't the time people have to give be marshalled around a particular release? Je ne comprends pas. Re:Why?
nicholas on 2003-05-01T19:38:58
Isn't development always done on the latest stable release?Development is always done on the development track, which branches from the latest major stable release. So current development is on 5.9.0, which branched from 5.8.0 at the time of 5.8.0's release. However, bug fixes are also made where possible to the development release, and then merged back into the stable branch(es). So the upcoming 5.8.1 release will fix bugs found in 5.8.0, and this fixes will have first been made to 5.9.0.
What could happen, but is not, is that bug fixes in 5.8.x could be merged back into the 5.6.x branch, and further releases made, staring with 5.6.2. This wouldn't have the new features added in 5.8.0, but would provide users of 5.6.1 who are hitting bugs with a solution. Currently if people report that they have found a bug in 5.6.1, often we on perl5-porters have to respond that it's a known bug, fixed in 5.8.0, but as there isn't likely to be a 5.6.2 release your only option to see the back of it is to upgrade to 5.8.0. For large organisations, or anyone trying to stabilise on a particular perl version, such as 5.005_0x or 5.6.x, upgrading is not a trivial option.
There has been some history of continuing maintenance on more than one stable version simultaneously - for example 5.004_05 was released in April 1999, after 5.005_03. The fear I have is that your statement becomes "maintenance is only done on the latest stable release". Effectively we are now in such a situation - with the release of 5.8.0, activity on 5.6.x has ground to a halt.
We keep saying that when Perl 6 comes out we are not going to abandon Perl 5 or its users, but judging from our current activity patterns that's exactly what we're going to do. Porting something from Perl 5 to Perl 6 is not going to be the same as tweaking it from Perl 5.6 to perl 5.8. If we don't start demonstrating that we can maintain two stable versions of Perl 5, then people are going to start thinking that Perl 5 is going to get abandoned within the next two years. It's very hard to make a case to a manager or customer for a Perl solution if they think that it will be unsupported (and hence they infer unsupportable) within the project's lifetime. Hence with the status quo we could find that Perl 6 is killing off Perl's future rather than ensuring it.
Please don't read me as anti-Perl 6 - I'm not. The internals of Perl 5 are becoming increasingly difficult to maintain, given all the things that have been bolted onto them (overloading, threads, UTF8, etc). They won't last - we need Perl 6. I'm just saying that we need to manage the transition carefully, and make it clear now that we will be able to, lest we scare people away to other languages
Re:Why?
inkdroid on 2003-05-01T21:31:51
Currently if people report that they have found a bug in 5.6.1, often we on perl5-porters have to respond that it's a known bug, fixed in 5.8.0, but as there isn't likely to be a 5.6.2 release your only option to see the back of it is to upgrade to 5.8.0. For large organisations, or anyone trying to stabilise on a particular perl version, such as 5.005_0x or 5.6.x, upgrading is not a trivial option.I would argue that this is as it should be. I imagine Perl developers have enough work already, and maintaining old versions could potentially be the straw that breaks the camels back. If upgrading is an issue in particular organizations (and I've been in one) then I think such organizations need to figure out why it is an issue, fix it, and move along. If they are worried about upgrading Perl then they'll be worried about upgrading other stuff too (OS, RDBMS, etc). Fear of upgrade is a paralyzing and incoherent sort of fear...as most fears are I suppose...
If we don't start demonstrating that we can maintain two stable versions of Perl 5, then people are going to start thinking that Perl 5 is going to get abandoned within the next two years. It's very hard to make a case to a manager or customer for a Perl solution if they think that it will be unsupported (and hence they infer unsupportable) within the project's lifetime. Hence with the status quo we could find that Perl 6 is killing off Perl's future rather than ensuring it.Perl 5.8.0 was released while development of Perl 6 was going full steam ahead, so it looks to me (from the outside) that the uber Perl hackers are handling the situation well. But I guess you must see a different picture being on the inside of this process.
The response hasn't been anything to get excited about, unfortunately. I got exactly three messages, two from Tim Bunce and Abigail on p5p, and another one privately from a patch author suggesting his patch for possible inclusion. I don't think this reflects a reasonable amount of interest in 5.6.2, so I have put it on the back-burner for now.
I'll certainly reevaluate this decision if and when I get more interest in 5.6.2. (See the URL above for exactly what I mean by "interest".)
