6 ms·

I Botched a Perl 6 Release

121 points by zoffix222 10y ago

jeffehobbs 10y ago
Great headline, good read.
Zekio 10y ago
Always wondered how coding in Perl is, guess I will have some fun with it tomorrow :)
- meddlepal 10y ago
  Perl is a great language. I haven't had an op to use 6 yet but 5 is great for small programs. The big problem with Perl is it requires discipline to prevent creating a mess for your team or eventual successor.
  - krupan 10y ago
    Or yourself a few months down the road.
  - dozzie 10y ago
    It's not like Python or Ruby are much better in this regard.
    - rimantas 10y ago
      Except they are.
      - dozzie 10y ago
        This comment sounds like you've never worked on any program larger than few hundreds lines. All three languages implement the same programming paradigm and neither of them enforce (or even suggests) any structure whatsoever, so you easily end up with the same mess/spaghetti, no matter the language. Of course Perl adds some idioms of its own on top of it, but (a) not that many as most people like to attribute to Perl, (b) most of the idioms are syntax sugar, and (c) most of the mess comes from program structure, not from superficial things like syntax.
  - pcollinsmokonut 10y ago
    I completely agree with you. Perl is absolutely terrible for basic oo. Basic getters and setters needs the moose module which instantly slows down your code base beyond. I'm a very competent oo perl developer. I recently wrote a complex large platform in Perl5. It's simply not good enough. In addition cpan is like walking the dungeons of moria. amazing relics of complexity frozen in time.
    - raiph 10y ago
      > Perl is absolutely terrible for basic oo. To clarify for readers who might not know... * Perl 5 (the language this comment appears to focus on) and Perl 6 (the language the OP is about) are different languages in the same family, like Common Lisp and Clojure. * Perl 6 OO is syntactically and semantically elegant. "In using Perl 6, one of the things that constantly floors me is how elegant objects are..." [1]. * Perl 6, which has this elegant OO built in, outperforms Perl 5 + Moose for some things and trails it for others. [1] https://www.reddit.com/r/perl6/comments/4ud7vc/a_python_guy_in_perl_6_object_land/ https://www.reddit.com/r/perl6/comments/4ud7vc/a_python_guy_...
- PeCaN 10y ago
  Obligatory to point out that Perl and Perl6 are quite different languages, and the latter is meant to supplement, not replace, the former. That said, both Perls are nice languages. Personally I prefer Perl 5 slightly, but both are fun to use, if confusing at first. (Perl, especially Perl 5, seems extremely arbitrary and nonsensical until you “get it”.)
13of40 10y ago
Maybe it's just me, but I've worked with a handful of source control systems over the years, and none of them (not even git) has done a terrific job of encapsulating the #1 scenario, which is "I copied some stuff locally and changed it and now I want to put it back on the server so other people can get my stuff (and of course I want undo in case I mess up and merge in case we both change the same file)" without inventing their own special opaque language and concepts for everything. We all intuitively understand file systems somehow but with source control it's way too easy to miss something subtle and end up with a steaming pile of merge conflicts, broken pulls, incomplete fetch requests, unpublished tags, and borked integrations instead of your awesome code ending up on the server so others can share in the awesomeness.
- scrollaway 10y ago
  Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results. In other word, git's great internally... externally it just has a poor UI. But what's new there.
  - ben_jones 10y ago
    I think it's a problem that you don't need to know Git that well to use it productively. Once you get the basic commands you can pretty much put away Git's documentation for a few years until something goes particularly wrong. It's been on my "list" for a long time now to deep dive into it but I've just never had the impetus to do so despite the fact that I use Git every single day.
    - ufo 10y ago
      I think the real problem is that "knowing git that well" is even a thing. If git's interface were more predictable and if its abstractions were less leaky, learning the basic commands would be enough and noone would ever need to do a deep dive into the documentation. I finally realized this after reading this xkcd comic[1]. Now I'm happily using mercurial (with hg-git) whenever I expect that I will need to do something nontrivial. https://xkcd.com/1597/ https://xkcd.com/1597/
aftbit 10y ago
Why build some new tool to do builds and releases? Why not use something existing like Jenkins or CircleCI? The biggest advantage is that other people will already know how to use it and how it works, unlike anything you build by hand.
- matt_wulfeck 10y ago
  My experience tells me that since everyone's build and release cycle is such a unique flower of hackiness that building and maintaining your own pipeline is actually easier than trying to fit everything into the community plugins of Jenkins. Also have you been on Jenkins recently? It looks and feels like butt.
  - skolsuper 10y ago
    How recently? Nowadays, Jenkins is looking half-decent again imo. Also, I think you can do literally anything in Jenkins that you can do with a custom tool, without really twisting it out of shape.
  - zanchey 10y ago
    The uniqueness of flowers seems to be the driver of the Buildbot philosophy.
cesarb 10y ago
> I run my gr alias for git pull --rebase to bring in the new changes The mistake was blindly using git rebase. History rewriting (which includes not only rebase but also amend) should be done with care, and never on history which has already been published (with a few special exceptions, but unless you really know what you're doing -- don't). The correct thing to do, since the commit was already pushed, would have been "git pull" without the --rebase, and then pushing the resulting merge commit. Getting in the habit of doing "git pull --rebase" every time is not a good idea; better have a "dirtier" history full of merges, than have to untangle messes like this one later.
- skolsuper 10y ago
  The commit wasn't already pushed though. The problem was with the semantics of a 'tag' in git being immutable, and not being rebased along with the commit and the branch, then getting pushed anyway.
- zzalpha 10y ago
  I don't even like the habit of using "git pull". When training folks I start by introducing them to "git fetch" and manually merging or rebasing on the remote tracking branch so they're fully in control of the process while understanding what's going on. Only after people grok that do I mention "git pull", and only in passing while discouraging its use.
  - rimantas 10y ago
    So basically you want them each time to do the job that git pull does right 99.999% of the time?
    - MichaelBurge 10y ago
      I don't know about him, but yes it's what I do too and I recommend it.
  - svens_ 10y ago
    I agree with that. I have an alias for "git pull --ff-only", which I use often though. It's faster than manually doing the fetch and then merge/rebase. If it succeeds you're at the newest version, if not you can still decide whether to merge or rebase. This should be the default behavior for git pull in my opinion.
tux1968 10y ago
That's a very interesting consequence of a git rebase. Would be nice if git warned that a tag would become stale in such a situation. Could even make an argument that it should be automatically updated.
- skolsuper 10y ago
  Definitely arguable, if git can see the tag is not on the remote yet. The problem is git can't tell if the tag is not on any remote, so just not moving them ever is always the safe choice. This could have been prevented by using "the cactus model" of git branching (sorry no link to source as am on mobile, Google should find it tho) where releases are branches, not tags.
joneholland 10y ago
Please just use Jenkins or TeamCity.
steveklabnik 10y ago
Releases are hard. With Rust, our nightly releases are 100% automated, but stable releases are not. https://forge.rust-lang.org/release-process.html https://forge.rust-lang.org/release-process.html For 1.11, we had two things go wrong: 1. stable docs got accidentally deleted, so we had a small amount of downtime before the new ones went up. 2. We recently moved the website to be i18n-able, and there was a subtle bug with Cloudfront invalidation tokens. So the site was updated, but the older version was still being shown for a bit. We could and maybe will make this 100% automated in the future. There's always so much work to do...
deleted 10y ago
[deleted]
johnchristopher 10y ago
So, it turns out we need AI to handle GIT.
rahkiin 10y ago
I mostly use pull, fetch and stash when I can't pull because of local changes. I have a hook on my gitserver to disallow force push: I never rebase. But I can't even rebase the history that is published. Bow I can't screw up too badly :) I really recommend disabling forcepush. Amend can still be used as long as you did not push yet. I don't mind 'oops a typo'-kind of commit messages. It happens.
rihegher 10y ago
"A robot doesn't care if it has to rebuild from scratch a hundred times while you're trying to debug a release-blocker (OK, I think it doesn't care... any robots' rights activists in the audience to tell me I'm wrong?)" :)
- JonnieCache 10y ago
  Yep, that's a thing, albeit currently an ironic thing: https://www.reddit.com/r/botsrights/ https://www.reddit.com/r/botsrights/
RubyPinch 10y ago
Learning question: so the tag was on an orphaned commit? What ways could this be resolved? The obvious and chosen one was to tag a new release and explain to people that the old one isn't accessible because of a muck up. Would of merging it back in worked? that would of fixed the "<nwc10> the tag is for a commit which is not a parent of nqp master" right?
- _ikke_ 10y ago
  The commit is not orphaned, because the tag is still pointing to it, but it's indeed not reachable from a branch anymore. git does not update local tags when the tag has changed remotely (see "on retagging" in the git tag man-page), so it would have to be a different tag. Merging it back would be confusing, because you know have the old branch and the new branch in your history. It would cause the tag to be reachable again from master though.
wscott 10y ago
This is where I have to point out that this would have been unlikely to happen with BitKeeper. :) BitKeeper doesn't provide a 'pull --rebase' and instead puts this in separate commands 'bk pull; bk collapse -e@; bk citool'. By default, collapse will refuse to replace an already released cset. Yeah less powerful, but we believe more predictable. Also, tags are fully revisioned controlled and propagate with every pull. You can move a tag to another revision and that operation becomes its own cset that propagates. www.bitkeeper.org
- abstractbeliefs 10y ago
  Maybe so, but have the licensing and philosophical reasons that led Torvalds to move the kernel away from BitKeeper been resolved? Until that can be said and news of that disseminated widely, I think many open source projects will consider BitKeeper as simply not having enough of a technical edge over Git to discount the cultural penalties (namely, "bad" reputation withing FLOSS and smaller population of users).
  - wscott 10y ago
    I fully understand your concerns, which it why I try to post about bk periodically. Go look at bitkeeper.org, we are now fully open source and published under a plain Apache 2.0 license. No additional license or restrictions. So we can be as evil as we want and you are still safe to use it. ;-)
  - asjo 10y ago
    BitKeeper was open sourced in May (Apache 2.0 licensed). The news was disseminated quite widely: * https://lwn.net/Articles/686896/ https://lwn.net/Articles/686896/ * https://news.ycombinator.com/item?id=11667494 https://news.ycombinator.com/item?id=11667494
- luckydude 10y ago
  And open source and has submodules that actually work and has a binary manager that works for world wide development (no single server). Oh, and has bk fast-import so any git project can try it out. And of course has bk fast-export so you can bail out if you don't like it. Incremental fast-import coming.
pcollinsmokonut 10y ago
Git just tries too hard. Worst UI and lexicon. There is this charisma around git that I simply don't understand. Errors like this are avoidmake. Supporters explain it away as user error.

121 points by zoffix222 10y ago

jeffehobbs 10y ago

Great headline, good read.

Zekio 10y ago

Always wondered how coding in Perl is, guess I will have some fun with it tomorrow :)

meddlepal 10y ago
Perl is a great language. I haven't had an op to use 6 yet but 5 is great for small programs. The big problem with Perl is it requires discipline to prevent creating a mess for your team or eventual successor.
- krupan 10y ago
  Or yourself a few months down the road.
- dozzie 10y ago
  It's not like Python or Ruby are much better in this regard.
  - rimantas 10y ago
    Except they are.
    - dozzie 10y ago
      This comment sounds like you've never worked on any program larger than few hundreds lines. All three languages implement the same programming paradigm and neither of them enforce (or even suggests) any structure whatsoever, so you easily end up with the same mess/spaghetti, no matter the language. Of course Perl adds some idioms of its own on top of it, but (a) not that many as most people like to attribute to Perl, (b) most of the idioms are syntax sugar, and (c) most of the mess comes from program structure, not from superficial things like syntax.
- pcollinsmokonut 10y ago
  I completely agree with you. Perl is absolutely terrible for basic oo. Basic getters and setters needs the moose module which instantly slows down your code base beyond. I'm a very competent oo perl developer. I recently wrote a complex large platform in Perl5. It's simply not good enough. In addition cpan is like walking the dungeons of moria. amazing relics of complexity frozen in time.
  - raiph 10y ago
    > Perl is absolutely terrible for basic oo. To clarify for readers who might not know... * Perl 5 (the language this comment appears to focus on) and Perl 6 (the language the OP is about) are different languages in the same family, like Common Lisp and Clojure. * Perl 6 OO is syntactically and semantically elegant. "In using Perl 6, one of the things that constantly floors me is how elegant objects are..." [1]. * Perl 6, which has this elegant OO built in, outperforms Perl 5 + Moose for some things and trails it for others. [1] https://www.reddit.com/r/perl6/comments/4ud7vc/a_python_guy_in_perl_6_object_land/ https://www.reddit.com/r/perl6/comments/4ud7vc/a_python_guy_...
PeCaN 10y ago
Obligatory to point out that Perl and Perl6 are quite different languages, and the latter is meant to supplement, not replace, the former. That said, both Perls are nice languages. Personally I prefer Perl 5 slightly, but both are fun to use, if confusing at first. (Perl, especially Perl 5, seems extremely arbitrary and nonsensical until you “get it”.)

13of40 10y ago

Maybe it's just me, but I've worked with a handful of source control systems over the years, and none of them (not even git) has done a terrific job of encapsulating the #1 scenario, which is "I copied some stuff locally and changed it and now I want to put it back on the server so other people can get my stuff (and of course I want undo in case I mess up and merge in case we both change the same file)" without inventing their own special opaque language and concepts for everything. We all intuitively understand file systems somehow but with source control it's way too easy to miss something subtle and end up with a steaming pile of merge conflicts, broken pulls, incomplete fetch requests, unpublished tags, and borked integrations instead of your awesome code ending up on the server so others can share in the awesomeness.

scrollaway 10y ago
Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results. In other word, git's great internally... externally it just has a poor UI. But what's new there.
- ben_jones 10y ago
  I think it's a problem that you don't need to know Git that well to use it productively. Once you get the basic commands you can pretty much put away Git's documentation for a few years until something goes particularly wrong. It's been on my "list" for a long time now to deep dive into it but I've just never had the impetus to do so despite the fact that I use Git every single day.
  - ufo 10y ago
    I think the real problem is that "knowing git that well" is even a thing. If git's interface were more predictable and if its abstractions were less leaky, learning the basic commands would be enough and noone would ever need to do a deep dive into the documentation. I finally realized this after reading this xkcd comic[1]. Now I'm happily using mercurial (with hg-git) whenever I expect that I will need to do something nontrivial. https://xkcd.com/1597/ https://xkcd.com/1597/

aftbit 10y ago

Why build some new tool to do builds and releases? Why not use something existing like Jenkins or CircleCI? The biggest advantage is that other people will already know how to use it and how it works, unlike anything you build by hand.

matt_wulfeck 10y ago
My experience tells me that since everyone's build and release cycle is such a unique flower of hackiness that building and maintaining your own pipeline is actually easier than trying to fit everything into the community plugins of Jenkins. Also have you been on Jenkins recently? It looks and feels like butt.
- skolsuper 10y ago
  How recently? Nowadays, Jenkins is looking half-decent again imo. Also, I think you can do literally anything in Jenkins that you can do with a custom tool, without really twisting it out of shape.
- zanchey 10y ago
  The uniqueness of flowers seems to be the driver of the Buildbot philosophy.

cesarb 10y ago

> I run my gr alias for git pull --rebase to bring in the new changes The mistake was blindly using git rebase. History rewriting (which includes not only rebase but also amend) should be done with care, and never on history which has already been published (with a few special exceptions, but unless you really know what you're doing -- don't). The correct thing to do, since the commit was already pushed, would have been "git pull" without the --rebase, and then pushing the resulting merge commit. Getting in the habit of doing "git pull --rebase" every time is not a good idea; better have a "dirtier" history full of merges, than have to untangle messes like this one later.

skolsuper 10y ago
The commit wasn't already pushed though. The problem was with the semantics of a 'tag' in git being immutable, and not being rebased along with the commit and the branch, then getting pushed anyway.
zzalpha 10y ago
I don't even like the habit of using "git pull". When training folks I start by introducing them to "git fetch" and manually merging or rebasing on the remote tracking branch so they're fully in control of the process while understanding what's going on. Only after people grok that do I mention "git pull", and only in passing while discouraging its use.
- rimantas 10y ago
  So basically you want them each time to do the job that git pull does right 99.999% of the time?
  - MichaelBurge 10y ago
    I don't know about him, but yes it's what I do too and I recommend it.
- svens_ 10y ago
  I agree with that. I have an alias for "git pull --ff-only", which I use often though. It's faster than manually doing the fetch and then merge/rebase. If it succeeds you're at the newest version, if not you can still decide whether to merge or rebase. This should be the default behavior for git pull in my opinion.

tux1968 10y ago

That's a very interesting consequence of a git rebase. Would be nice if git warned that a tag would become stale in such a situation. Could even make an argument that it should be automatically updated.

skolsuper 10y ago
Definitely arguable, if git can see the tag is not on the remote yet. The problem is git can't tell if the tag is not on any remote, so just not moving them ever is always the safe choice. This could have been prevented by using "the cactus model" of git branching (sorry no link to source as am on mobile, Google should find it tho) where releases are branches, not tags.

joneholland 10y ago

Please just use Jenkins or TeamCity.

steveklabnik 10y ago

Releases are hard. With Rust, our nightly releases are 100% automated, but stable releases are not. https://forge.rust-lang.org/release-process.html https://forge.rust-lang.org/release-process.html For 1.11, we had two things go wrong: 1. stable docs got accidentally deleted, so we had a small amount of downtime before the new ones went up. 2. We recently moved the website to be i18n-able, and there was a subtle bug with Cloudfront invalidation tokens. So the site was updated, but the older version was still being shown for a bit. We could and maybe will make this 100% automated in the future. There's always so much work to do...

deleted 10y ago

[deleted]

johnchristopher 10y ago

So, it turns out we need AI to handle GIT.

rahkiin 10y ago

I mostly use pull, fetch and stash when I can't pull because of local changes. I have a hook on my gitserver to disallow force push: I never rebase. But I can't even rebase the history that is published. Bow I can't screw up too badly :) I really recommend disabling forcepush. Amend can still be used as long as you did not push yet. I don't mind 'oops a typo'-kind of commit messages. It happens.

rihegher 10y ago

"A robot doesn't care if it has to rebuild from scratch a hundred times while you're trying to debug a release-blocker (OK, I think it doesn't care... any robots' rights activists in the audience to tell me I'm wrong?)" :)

JonnieCache 10y ago
Yep, that's a thing, albeit currently an ironic thing: https://www.reddit.com/r/botsrights/ https://www.reddit.com/r/botsrights/

RubyPinch 10y ago

Learning question: so the tag was on an orphaned commit? What ways could this be resolved? The obvious and chosen one was to tag a new release and explain to people that the old one isn't accessible because of a muck up. Would of merging it back in worked? that would of fixed the "<nwc10> the tag is for a commit which is not a parent of nqp master" right?

_ikke_ 10y ago
The commit is not orphaned, because the tag is still pointing to it, but it's indeed not reachable from a branch anymore. git does not update local tags when the tag has changed remotely (see "on retagging" in the git tag man-page), so it would have to be a different tag. Merging it back would be confusing, because you know have the old branch and the new branch in your history. It would cause the tag to be reachable again from master though.

wscott 10y ago

This is where I have to point out that this would have been unlikely to happen with BitKeeper. :) BitKeeper doesn't provide a 'pull --rebase' and instead puts this in separate commands 'bk pull; bk collapse -e@; bk citool'. By default, collapse will refuse to replace an already released cset. Yeah less powerful, but we believe more predictable. Also, tags are fully revisioned controlled and propagate with every pull. You can move a tag to another revision and that operation becomes its own cset that propagates. www.bitkeeper.org

abstractbeliefs 10y ago
Maybe so, but have the licensing and philosophical reasons that led Torvalds to move the kernel away from BitKeeper been resolved? Until that can be said and news of that disseminated widely, I think many open source projects will consider BitKeeper as simply not having enough of a technical edge over Git to discount the cultural penalties (namely, "bad" reputation withing FLOSS and smaller population of users).
- wscott 10y ago
  I fully understand your concerns, which it why I try to post about bk periodically. Go look at bitkeeper.org, we are now fully open source and published under a plain Apache 2.0 license. No additional license or restrictions. So we can be as evil as we want and you are still safe to use it. ;-)
- asjo 10y ago
  BitKeeper was open sourced in May (Apache 2.0 licensed). The news was disseminated quite widely: * https://lwn.net/Articles/686896/ https://lwn.net/Articles/686896/ * https://news.ycombinator.com/item?id=11667494 https://news.ycombinator.com/item?id=11667494
luckydude 10y ago
And open source and has submodules that actually work and has a binary manager that works for world wide development (no single server). Oh, and has bk fast-import so any git project can try it out. And of course has bk fast-export so you can bail out if you don't like it. Incremental fast-import coming.

pcollinsmokonut 10y ago

Git just tries too hard. Worst UI and lexicon. There is this charisma around git that I simply don't understand. Errors like this are avoidmake. Supporters explain it away as user error.