Discuss
  • PRs policy

PRs policy

# Raul-Sebastian Mihăilă (7 years ago)

A month ago I opened a github issue ( tc39/ecma262#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 ( tc39/ecma262#666) 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 ( esdiscuss.org/topic/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?
# Jordan Harband (7 years ago)

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.