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.miha...@gmail.com> wrote: > A month ago I opened a github issue (https://github.com/tc39/ > 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 (https://github.com/tc39/ecma262/pull/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 (https://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? > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
