Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I really like the Ubuntu model of designating certain releases as long-term support releases.

    If Perl were to release twice a year, then it could mark a release every 3 years or so as a long-term support release, and support it for maybe 5 years (the idea being you have 2 years from the _next_ LTS to upgrade).

    Feel free to tweak those numbers as needed, but I think the general idea is sound. Supporting every release for 8-10 years (or 5 years) is nuts. Supporting no release for longer than a year seems proble

    • Number of FTEs at SAP AG: over 51,000.

      Number of FTEs at Canonical, Ltd.: over 200.

      Number of FTEs maintaining Perl: 0.

      I should write in more detail what I'd like to see, but if I were in charge, I'd have yearly major releases. Perl 5.12 comes out in January 2010. There are three quarterly releases: Perl 5.12.1 in April, Perl 5.12.2 in July, and Perl 5.12.3 in October. p5p strongly encourages people to upgrade to the newest quarterly release, when possible. These quarterly releases only contain bugfixes.

      • The number of employees is largely irrelevant.

        It's an issue of what the market and users demand, and what (as a result) we feel will make them happier and more productive. Hence "support"...

        My point with the long timeline was that for the corporates, "Every 8-10 years, on a Saturday afternoon" is what they want. And it's these people that employ a whole lot of us, and in 5s and 10s and 20s at a time.

        It's all well and good to deprecate lots of things quickly, and move in different directions each year. But i

        • It's an issue of what the market and users demand....

          If businesses want something they're not getting from the Perl development process, they should do what we expect individuals who want something from the Perl development process: contribute something more than their desires.

          The number of employees is largely irrelevant.

          I'll give you one reason SAP software is expensive: it costs a lot to maintain software for a decade. Where are those resources in the Perl 5 world? They do not exist now. Where wil

          • If businesses want something they're not getting from the Perl development process, they should do what we expect individuals who want something from the Perl development process: contribute something more than their desires.

            It seems to me that businesses who are using Perl currently are getting what they want. Versions of Perl start having real trouble when they are 5-10 years old. In over a decade as a Perl programmer I have never been targeting a production system with a version of Perl that was under

            • You don't have to release new versions of old software every 15 minutes to support it.

              I disagree with your arguments, but I take them seriously. Why don't mine deserve the same respect?

              • s/minutes/weeks/ or s/minutes/months/. Now can you bother honestly addressing the rest of the post?

                I suspect the real answer is "chromatic wants Perl to change quickly in XYZ ways; others want it to remain static in ABC ways; no one will convince anyone of anything." But this is just nerd-politics of the most pathetic sort.

                • Now can you bother honestly addressing the rest of the post?

                  What's the point? I've explained my point several times in several places. If people are still arguing against strawmen, no amount of logic on my part can possibly help.

                  Adam waves aside the point that sometimes work doesn't get done without people. I wonder how he explains that Perl 5 RCs do not get tested. (One rather suspects that SAP begs and pleads with very few of its 53,000+ employees to run through a test suite and a test matrix representing real world programs its paying customers rely on.)

                  Ben conveniently ignores that I believe quarterly releases are achievable, useful, and far better than what we have now to suggest that I want to remove features willy-nilly.

                  How do you recommend I respond to that? Sarcasm? Mockery? Yet another patient explanation that no, that's not what I believe and no, I've never suggested that, and if they read what I wrote and took it at face value they'd learn a lot more about what I believe, and meanwhile we've released 29 stable monthly versions of Parrot in a row and have increasing confidence in our roadmap for the next 24?

                  Releasing stable code on a predictable time frame is not impossible. Parrot does it. OpenBSD does it. Rakudo does it. The Linux kernel does it. Ubuntu does it. GNOME does it.

                  Tell me those projects haven't improved dramatically since the release of Perl 5.10.

                  • If you believe you have already explained, then a polite "I think I addressed that here" with a link only takes the same amount of time as a non-responsive response.

                    You "believe quarterly releases are achievable, useful, and far better than what we have now," but as a Perl user I kind of like what we have. My scripts keep running, and from time to time the interpreter gets a bit faster, memory leaks go away, and new features appear. Yes, I am anxious to use given/when and some of the new regex features, b

                  • Gnome managed to screw up session management big time, and Ubuntu (and FC10) packaged it. [livejournal.com] Clockwork release cycles can bring failure as well as success.

                    • I debated putting GNOME in that list; I disagree with some of its philosophies (gconf is no substitute for a working configuration dialog, for example) -- but overall I do believe it's better after a few regular releases.

                      Software isn't perfect. That's why we have followon releases.