Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

1,000 git commits is not "almost comes to a halt" (was Hockey Sticks)

by raiph (Hermit)
on Jan 23, 2012 at 02:19 UTC ( #949299=note: print w/ replies, xml ) Need Help??


in reply to Re: Scope Creep (was Hockey Sticks))
in thread Hockey Sticks

But it's worrysome that a project almost comes to a halt if a single person, for whatever reason, is suddenly unavailable. That's not a sign a project is anywhere near the state of "mature". If I were an IT manager of a company that may consider switching to Perl6 at some time in the future, I'd take notice.
Sigh. Before I go on, I must acknowledge frustration.

On what basis are you saying that Rakudo development has almost come to a halt?

Let's ignore all the work on the overall ecology, like changes to the test suite (lots of that). the spec, the nice work on pod, panda, etc. Let's forget Parrot even though they have stated that their work is driven by Rakudo's needs. Let's forget branches not yet merged back in, even though it's recognised that there are more branches waiting to land than usual.

In the less than 4 months since Patrick paused, there have been something like 1,000 commits to rakudo/rakudo and perl6/nqp (the main parts of the Rakudo compiler).


Comment on 1,000 git commits is not "almost comes to a halt" (was Hockey Sticks)
Re: 1,000 git commits is not "almost comes to a halt" (was Hockey Sticks)
by JavaFan (Canon) on Jan 23, 2012 at 13:45 UTC
    On what basis are you saying that Rakudo development has almost come to a halt?
    You were describing that the fact that Patrick no longer had time to work caused the announced releases to no longer happen. For an outsider, there's no difference between "no new releases because of X", "no new releases because of Y", or "no new releases because of Z", regardless whether "X", "Y", or "Z" are "no commits" or "one person no longer having time".
      You were describing that the fact that Patrick no longer had time to work caused the announced releases to no longer happen.
      No, I wasn't.

      Of the last 50 scheduled monthly compiler releases, only the August release (would have been 43rd) was skipped. Of the Rakudo Star releases, the only slip/skip was the 12th, which was delayed till this month (was at least anticipated by some to ship October/November). Aiui, these two releases are what you are referring to when you say "announced releases to no longer happen".

      The August compiler release was not skipped for the reason that you claimed that I claimed. As you will see if you read contemporary records such as the September 9th post on the rakudo.org home page, it was Patrick (clearly not absent) who was saying things like "far better ... delaying a release than to issue a release that we know will cause problems for our clients.". They could easily have cut an August release, but chose not to. As a customer, I would be pleased that they made such a decision. Aiui, the primary cause was the nom rewrite.

      Similarly, the 12th Star release was delayed against a backdrop of the nom rewrite and Patrick dropping out and the possibility he might rejoin. These were some considerations, but the cause was jnthn's decision to keep delaying. Was his decision a good one?

      What would you have done? The project's decision was to keep doing the monthly releases, so users who wanted the latest had that as an option, but not the Star release, so users who wanted stability had a good option. I think they made the right decision.

        In an earlier post, you wrote:

        The original plan was for Star releases (they refer to these as "distributions") to be on a quarterly release schedule in 2011. They did Jan, a couple of April variants, and July. The next was scheduled for October. By December, jnthn concluded he needed to go ahead with a Star release ... and now has a Star release nearly ready.

        Let me give you my history.

        One year ago, in January 2010, Rakudo Star was unusable for my business projects. While I'd objected to the nom fork-and-rewrite, it was clear that the Rakudo developers were going ahead with it anyway. I decided against using whatever the "stable" branch of Star was at the time, because it was also clear that it was a branch abandoned to bitrot in the hopes that nom would be available sooner rather than later. (Want your statistics to mean something? Count the number of commits to nom versus its predecessor. QED.)

        Sure, there were a couple of Star releases in 2010, but they were all off of the abandoned branch. That means no ecosystem (such as it is). That means no bugfixes. That means it's further away from the specification. None of these are reasons to use it. (Does it even compile against a modern Parrot? Has anyone tested that?)

        It's almost a year later, and nom isn't up to the point where its predecessor was. (It's ahead in some ways, but it's regressed in others. If you're claiming that Star provides stability, you don't regress.)

        It doesn't really matter why releases were skipped or slipped. What matters is that a fork and rewrite underwent unsurprising scope creep. There went a year.

        Do the Rakudo developers deserve applause for running so hard to stay mostly in place, Red Queen style? I say no.

        What would you have done?

        I wouldn't have undertaken a year-long rewrite, and even if I had, I wouldn't have crammed more features in it.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://949299]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2014-08-30 07:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (291 votes), past polls