PRs policy

Jordan Harband ljharb at
Sun Feb 4 17:45:54 UTC 2018

If we had such a policy, and a PR hit that time window without meeting the
criteria, I'd expect that it would be closed without being merged.

In other words, such a policy would cause open unmerged PRs to be *closed*
- but in no way could, or should, such a policy accelerate *merging*.

The only way that PR can be merged is if tests are added first.

- Jordan

On Sun, Feb 4, 2018 at 1:08 AM, Raul-Sebastian Mihăilă <
raul.mihaila at> wrote:

> A month ago I opened a github issue (
> ecma262/issues/1061) in which I asked whether or not TC39 should have a
> policy WRT the time frame in which a PR should be merged. I mentioned that
> there was currently an open PR (
> which had consensus, for a confirmed bug that was reported one year and a
> half ago.
> It's obviously not always possible to set expectations WRT to time. It's
> possible that at some point a difficult to understand or
> difficult/impossible to fix bug is found. However, in this case, the PR
> already achieved consensus in TC39.
> A year ago I held a course about the Javascript object model, invariants
> and internal methods. I mentioned the existing bugs related to proxies. I
> mentioned that there was a PR that would soon be merged and since not many
> people were using proxies at that time, the bugs weren't a serious concern.
> One year later, the PR is still not merged.
> This thread isn't about good or bad, although we can think about
> expectations people might have. For instance, in general, when somebody
> works on something, if that thing isn't working properly, it is expected
> that that somebody would fix that issue. Also, as we know, in Javascript
> the older a bug is, the greater the risk that somebody will start depending
> on the bad behavior, which can make it more difficult to fix the bug. It's
> also important to mention that, as we all know, TC39 did a great job
> improving the spec over time.
> This thread is about whether or not people can have some expectations WRT
> the time frame in which a bug is fixed. I believe it's easier to set
> expectations WRT PRs that already have consensus and I believe that in this
> case one year and a half is a rather long period. It would be nice if the
> community could have some sort of expectations in the simpler cases.
> In that github issue I was told that the PR needed tests (which was
> already obvious) and I was suggested to contribute the tests if I wanted to
> push the feature forward. An important aspect of this story is that the
> initial bug that triggered the whole discussion about these issues was
> found by myself, a volunteer (
> object-freezing-proxies-should-freeze-or-throw). The other issues were
> found and the fixes in the PR for the proxies internal methods were done by
> Claude Pache, which as far as I'm aware also did this voluntary (see the PR
> link above). The way I see it, most of the work that was done to push this
> feature forward was already done by volunteers that are not part of TC39. I
> personally am busy with other work and stuff that don't allow me to do the
> testing for this PR.
> Therefore:
> 1) Should TC39 have a policy WRT the time frame in which a PR should be
> merged?
> 2) Does a year and a half look like a long period for a PR with consensus
> that hasn't been merged?
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list