Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

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

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


in reply to Re: 1,000 git commits is not "almost comes to a halt" (was Hockey Sticks)
in thread Hockey Sticks

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.


Comment on Re^2: 1,000 git commits is not "almost comes to a halt" (was Hockey Sticks)
Rakudo Star, Red Queen Edition
by chromatic (Archbishop) on Jan 23, 2012 at 23:46 UTC

    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.

      Do the Rakudo developers deserve applause for running so hard to stay mostly in place {for one year}, Red Queen style? I say no.
      I actually don't know whether you are right or not about your Red Queen dig, because I have not tried the new compiler. I'd be absolutely stunned if you were right.

      The nom branch was started just after the Jan 2011 Rakudo Star. The team is just about to publish the Jan 2012 Rakudo Star, the first using a compiler based on the nom branch you so disparage. If they've been running hard to stay mostly in place, there'll be little difference between the two. Perhaps it'll even have regressed. I'd love to see a serious comparison between the two, so:

      I challenge you and the Rakudo team to write dueling comparisons. I think it would only make sense to do so using a powerful, modern machine (loads of RAM, multi-core cpu, fast disk, the works), because the Rakudo team has claimed a lot of speed optimization in the last year, but have voiced concern about its resource usage and have noted that they have not yet done space etc. optimization. However, you are free to stack the odds as you wish.

        I challenge you and the Rakudo team to write dueling comparisons.

        What a waste of everyone's time that would be. To repeat to you yet again, everyone who's looked at nom knows it has regressions against what it will eventually replace.

        the Rakudo team has claimed a lot of speed optimization in the last year

        Yes, and several of them I identified years ago. A few of them I volunteered to fix ages ago too, but they turned me down.

      chromatic, you have said yourself:

      Rakudo Star is a useful and usable subset of Perl 6 you can use right now.

      As I've consistently argued, it's up to you to decide what "useful" or "production" or "stable" mean.

      At that time you had used Rakudo Star and seemed to accept the subjective definition of notions like "useful" and "production".

      But I note that you introduced "stable". In the 2009 post announcing Rakudo Star Patrick himself explicitly focused on his discomfort with the moniker "stable", subjectively defined or not, in the context of Rakudo Star (let alone the in-development Rakudo compiler):

      So, once we eliminate the notion of "finished", the wording is often changed to try to make it more tractable, often by asking when there will be a "stable release". ... part of me thinks "Huh? Those questions don't really fit with the way things really happen in language development... "
      Rakudo Star is likely to be more stable than the plain Rakudo compiler, but it is clearly not something anyone should be building a business project on.
      One year ago, in January 2010, Rakudo Star was unusable for my business projects.
      s/2010/2011/.

      Was Rakudo Star ever usable for your business projects?

      While I'd objected to the nom fork-and-rewrite
      Do you think your objection was influenced by the fact that Rakudo (Star or otherwise) was unusable for your business projects?
      I decided against using whatever the "stable" branch of Star was at the time
      There are no (non-master) branches of Star, "stable" or otherwise.
      because it was also clear that it was a branch abandoned to bitrot
      New quarterly Star releases were published in April and July, with 200 commits after the creation of the compiler nom branch in February. Given the nature of Rakudo Star as it was intended (not as a basis for business projects!) its treatment seems reasonable to me and not consistent with "abandoned to bitrot".
      That means no bugfixes.
      Check the commit log. I see bug fixes.
      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.)
      You're confusing the Rakudo compiler and Rakudo Star.

      The Rakudo compiler appears to be far ahead of where it was a year ago in many regards, chiefly because of the nom branch, as one would expect.

      Rakudo Star, which is a package including many things, has not yet switched to the nom version of the compiler, so it can not have regressed due to the nom branch. As made clear near the start of this comment, while Rakudo Star is said to be more stable than the plain compiler, the team explicitly avoided stability promises of the sort that someone doing a business project might require.

      It is unfortunate that you misunderstood Rakudo Star's purpose and scope. I agree the team would be well advised to see if it can further clarify Rakudo Star's purpose and scope, and I will mention this on #perl6.

        In the 2009 post announcing Rakudo Star Patrick himself explicitly focused on his discomfort with the moniker "stable"...

        I was in the room with him! His concern as I recall was in part due to the fact that he (and everyone, really) rightly expected that the specification would change. It has.

        If you read my posts, you'll find out that that's never been my concern.

        Please do us both the courtesy of reading my posts.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (6)
As of 2014-09-01 18:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (15 votes), past polls