Thanks to all volunteer contributors.

208 views
Skip to first unread message

Jason Zaugg

unread,
Mar 31, 2013, 9:46:40 AM3/31/13
to scala-i...@googlegroups.com
I'm always amazed at the contributions we get from volunteers, despite the all the hurdles that one needs to clear.

Here's a list of my favourites:

https://twitter.com/search?q=%23scalacontrib&src=hash

Any others you remember, big or small, that deserve recognition? Tweet them to #scalacontrib.

-jason

Som Snytt

unread,
Apr 1, 2013, 3:15:36 AM4/1/13
to scala-internals
On Sun, Mar 31, 2013 at 6:46 AM, Jason Zaugg <jza...@gmail.com> wrote:
I'm always amazed at the contributions we get from volunteers, despite the all the hurdles that one needs to clear.


I've taken the trouble to incorporate Paul Phillips' helpful suggestions for the Pull Request Policy.  The obsolete version is still available at:

https://github.com/scala/scala/wiki/Pull-Request-Policy

Hi there, would-be pull request submitter!

After much discussion on scala-internals, with further discussions at
a dive bar favored by the core team, the requirements for pull requests
have been tightened up somewhat.

We appreciate your cooperation.  Remember, whenever a pull request
doesn't follow the guidelines, God kills a kitteh.

Your pull request should:
  - have been ignored on scala-internals. Serious PRs require an
    incubation period.
  - merge cleanly or at least be no more than two or three commits away
    from merging cleanly
  - two or three ordinary commits equal one paulp commit
  - consist of commits with impeccable commit messages, including grammar
    and spelling (Queen's English only)
    - for a bug fix, the title must look like "SI-1234 - Don't crash when
      moon is in wrong phase".  But don't use that exact title; that bug has
      been fixed already.
    - overall, think of the first line of the commit as a description of
      the code base which might be true today, but probably won't be true
      by the time you wake up tomorrow and review the result of the merge,
      so use the present tense -- that also makes them easy to laugh at
      when you read the release notes
    - backports should be tagged as [backport], back pain as [backpain],
      pain in the neck as [neckpain]
  - come with tests, or a test, or a test that tests something, or a test
    in pending, or explain in detail why it cannot be tested at all (and
    then describe in detail why we can't use the change).
    The test itself should:
    - be included in the commit for tests running under old partest, or
      included in the source file for partest with grandly unified tests,
      GUTtest.  GUTtest is a compiler plugin that applies a patch and its
      tests simultaneously, failing the build if the tests don't pass during
      compilation.  A full GUTtest build will reapply all commits since
      the beginning of time, which currently takes only about a day, or
      two days with -optimise.
    - be minimal, deterministic, stable (unaffected by irrelevant changes),
      easy to understand and review. There may be an impedance mismatch
      with the current codebase which is none of these things.
    - have minimal dependencies: a compiler bug should not depend on, e.g.,
      the Scala library. Unless, of course, the bug is a circular dependency.
    - typically fail before your fix is applied and succeed afterward; but
      we'll settle for it just passing more often after the fix than before.
  - pass the test suite, including spurious failures by the build bot
     - if the build fails for any reason, the request will be closed without
       further ado
     - you will not be permitted to push new commits to fix the problem
     - your github account will be quarantined
     - a commit is considered a unit of useful change
     - a bug is defined as a unit of useless change
     - community contributions are welcome in the form of spare change
  - be assigned to the correct reviewer (if you're not sure who, you should
    ask if you really should be submitting a PR in the first place)
  - get the green light from the reviewer ("LGTM", that is, "looks good to
    me", aka "LeGiTiMate")
  - this is not to be confused with 2L2C, i.e., "Too Legit to Commit". Under
    normal circumstances, only a paulp PR can be be 2L2C.
  - features which are desirable but which may incur irreversable technical
    debt or launch a cascade of typer bugs may be deemed: WAPBTEOYS, i.e.,
    "We are protected by the enormity of your stupidity."
  - if two reviewers post feedback with conflicting advice, static overload
    resolution is used to pick between them (see SLS 6.26.3)
  - review feedback may be addressed by pushing new commits to the request,
    if these commits stand on their own.  That means every commit must address
    an orthogonal concern and pass all tests.  That means each commit must
    have nothing to do with the other commits, except they have something to
    do with the JIRA issue.
    Keep in mind that two or three ordinary commits equal one paulp commit.

Fixes for random compiler bugs will be considered only if it is shown that
the bug is truly random.

Once all these conditions are met, and we agree with the change, and you buy
us a drink at our favorite dive bar, and we like you, we will merge your changes.

Please note: you are responsible for meeting these criteria!

### Pull request bot mechanics
* someday this may be automated, but please consider the following:
  * when you push new commits, please delete the comments with the old build
    results to avoid confusion
  * then label the issue 'pull request'
  * label the issue corresponding to your pull request (if you have permission)
    as 'tested' when the bot has reported on a successful build
  * then label it 'reviewed' when everyone has LGTM'd
  * optionally, add the label 'fed up with manual workflow'.
  * 'PLS REBUILD ALL' will force the bot to rebuild (if it feels like it)
  * Note that once the automated build bot is engaged, it cannot be disabled
    until it has completed its protocol:

YOU ARE IN DIRECT VIOLATION OF SCALA PULL REQUEST POLICY
YOU HAVE TWENTY SECONDS TO FIX THE TEST CASE
YOU HAVE FIFTEEN SECONDS TO FIX THE TEST CASE
THERE ARE STILL WHITESPACE DIFFERENCES
YOU HAVE TEN SECONDS TO FIX THE TEST CASE
IT DOES NOT PASS ON WINDOWS XP
YOU HAVE FIVE SECONDS TO FIX THE TEST CASE
I AM NOW AUTHORIZED TO USE PHYSICAL FORCE

Happy Easter! :rabbit: and April 1.

Jason Zaugg

unread,
Apr 1, 2013, 3:24:41 AM4/1/13
to scala-i...@googlegroups.com
On Mon, Apr 1, 2013 at 9:15 AM, Som Snytt <som....@gmail.com> wrote:

  - if two reviewers post feedback with conflicting advice, static overload
    resolution is used to pick between them (see SLS 6.26.3)

 +1. As we have done for implicit resolution, we can amortize the implementation complexity of static overload resolution by finding novel applications for the underlying "is-strictly-more-specific-than-or-at-least-probabilistically-less-vague-than" machinery.

-jason

Paul Phillips

unread,
Apr 3, 2013, 3:51:36 PM4/3/13
to scala-i...@googlegroups.com
On Mon, Apr 1, 2013 at 12:15 AM, Som Snytt <som....@gmail.com> wrote:
    The test itself should:

    - be minimal, deterministic, stable (unaffected by irrelevant changes),
      easy to understand and review. There may be an impedance mismatch
      with the current codebase which is none of these things.

I wish the basis of the humor had been that it ISN'T true.

Som Snytt

unread,
Apr 11, 2013, 8:00:38 PM4/11/13
to scala-internals
On Mon, Apr 1, 2013 at 12:15 AM, Som Snytt <som....@gmail.com> wrote:

    "We are protected by the enormity of your stupidity."

This is googlable, but for the record, it is a quote from "Notorious", which had recently played at a Hitchcock festival.

It's one of my very favorite films, so in that spirit, may I suggest that if Scala were a movie star, it would be Claude Rains: indeterminately European, an Old School hybrid, both object-oriented -- think of how he focuses in on the young Bulgarian refugee in Casablanca:

Annina: Monsieur Rick, what kind of a man is Captain Renault?
Rick: Oh, he's just like any other man, only more so.

Yes, Scala is just like any other language -- only more so!

Someone was willing to compromise her coding standards to make something higher-kinded type-check.  The conversation went something like:

Annina: Oh, monsieur, you are a programmer. If someone loved you very much, so that your happiness was the only thing that she wanted in the world, but she did a bad thing to make certain of it, could you forgive her?
Paulp: Nobody ever loved me that much. You want my advice? Go back to Bulgaria.

-- and functional (from Now, Voyager):

Dr Odersky: I thought you said you came here to have a nervous breakdown.
Charlotte/Scala: About that, I've decided not to have one.

I don't know if Claude Rains ever got the girl -- though in Casablanca he does get Humphrey Bogart, which is plenty -- but we do know that if we must exist as hybrids, compromised, mortal, we want to do it as Claude Rains.  If you had to be a monarch on the wrong side of the Lord, wouldn't you elect to be the King Herod of Claude Rains?

By the way, my initial inspiration for this parody was Knuth, which I am just reading (the way one lets drop that one is reading Moby Dick or the Bible -- before one dies).  In my attempt to work through Knuth, I wondered what if PRs, SIPs and the spec were required to be formulated in Knuth's style, with an algorithm for how to read this text, a ratings system with custom operator symbols).  Moreover, what if to modify the spec you had to upgrade the text formatter in which it was written?  Sometimes the first program written in a new language is the bootstrapped compiler itself -- or the Scalatex language used to produce the spec.

Come to think of it, if we had Scalatex, we'd have a linkable nightly version of the spec on the web, as well as the e-book version for iPad. But we might not have 2.8 collections and extension methods and macros.

For the record, scalatex.com is a Turkish supplier of t-shirts.  If the Scala store isn't selling "paulp fiction" tees yet, I hope they cut a deal with them.

Their home page asks: "What makes Scala so interesting?  Reliable -- and Best Price - Quality balance."

Paul Phillips

unread,
Apr 13, 2013, 11:08:30 AM4/13/13
to scala-i...@googlegroups.com

On Thu, Apr 11, 2013 at 5:00 PM, Som Snytt <som....@gmail.com> wrote:
Annina: Oh, monsieur, you are a programmer. If someone loved you very much, so that your happiness was the only thing that she wanted in the world, but she did a bad thing to make certain of it, could you forgive her?
Paulp: Nobody ever loved me that much. You want my advice? Go back to Bulgaria.

Pretty spooky because I'm sure I've had that conversation, verbatim.


Reply all
Reply to author
Forward
0 new messages