in reply to Re^3: When comment turns into disaster
in thread When comment turns into disaster

A similar point about other open source projects came up in the discussion following http://consttype.blogspot.com/2009/07/time-based-releases-in-open-source.html and Raphael countered by saying that big open source projects with regular release schedules and deprecation cycles have paid developers to help make that happen.

I don't know if he is entirely right, but your list contains no counterexamples to his hypothesis. But it is obvious regular releases are easier if you have a release manager for that purpose, like Samba has in Karolin Seeger. (She is sponsored by a German company named SerNet GmbH.)

Replies are listed 'Best First'.
Re^5: When comment turns into disaster
by chromatic (Archbishop) on Jul 07, 2009 at 23:45 UTC
    Raphael countered by saying that big open source projects with regular release schedules and deprecation cycles have paid developers to help make that happen.

    Dave Mitchell has received a TPF grant to make 5.10.1 happen. Booking.com also gave TPF $50,000 for Perl 5 development.

    But it is obvious regular releases are easier if you have a release manager for that purpose....

    Our experience with Parrot is that regular releases are easier -- even with volunteers -- if you have a dozen people who can make any given release, even if they have only a day's notice.

    I don't believe the problem is money.

      AFAIK Dave Mitchell's work on 5.10.1 is the first time that someone has been paid to release a version of Perl. Though Sarathy's work on the 5.005 series related enough to his day job at Active State that perhaps that qualified. As for the $50,000 grant, whatever it has been used for, it has not been used to make Raphael's life easier.

      Which brings us to a chicken and egg problem regarding releases. If you make releases often, you identify the issues with releasing and create infrastructure that makes it easier to release. If you don't, then every time you go to make a release, that infrastructure is not there. And things change enough between releases that it is hard to define what that infrastructure should be. So it is much, much easier to maintain a working process than to fix a broken one.

      I agree that the Perl 5 release process is broken. Which makes it easy to identify things that would make releases easier. You have identified many. However solving any one of them requires an investment of time and effort. Solving enough of them to make releases take a reasonable amount of effort would require a lot of time and effort. And this is time and effort devoted to something that most people don't like doing.

      If you enumerate issues in this case, I agree with you that money won't be the direct problem. You won't find that the bottleneck isn't that you didn't pay for the bandwidth to upload a changed file. However solving the direct problems requires an investment of time and effort. And money is a remarkably good way to get time and effort to be applied to boring problems. So while money isn't the problem, it is likely to be a necessary part of the solution.

        I believe we agree far more than we disagree.

        What now? How does the Perl community move on from a point where several people believe that the Perl 5 release process needs some major overhaul and other people strongly believe that even discussing that is, at this point, antisocial behavior?