| 19:31 | <dminor> | Hi :) I'm interested in getting started on upstreaming some of our tests (specifically these: https://searchfox.org/mozilla-central/source/js/src/tests/non262, that already run under the same test harness as other test262 tests...) Are there any guidelines on using the implementation-contributed directory? Are there any expectations around rewriting the tests to be runnable in other harnesses, or can I move them over as is? |
| 19:44 | <ptomato> | I'm not sure about implementation-contributed. I have some questions about it myself, that I was hoping to get clarified at tomorrow's maintainer meeting 😄 |
| 19:45 | <ptomato> | if these 'non262' tests already run under the test262 harness and are not particularly spidermonkey-specific, maybe you'd like to add them to the main test corpus anyway? |
| 19:48 | <dminor> | We have an import process that modifies the test262 tests to run under our own harness. The non262 tests also happen to run under this Mozilla harness. Submitting them to the main test corpus would be a huge amount of work, I think. |
| 19:49 | <dminor> | Would it make sense for me to drop into the meeting tomorrow to learn more about implementation-contributed? |
| 19:54 | <littledan> | dminor: that would be awesome to bring in those tests! I'm very happy that you're thinking about this. |
| 19:54 | <ptomato> | you're welcome to if you'd like! if it'd be a time sink for you, I can also try to figure it out and get back to you |
| 19:55 | <dminor> | Sure, I'll drop by, it would be good to get some context on how test262 is maintained. Thanks! |
| 19:59 | <littledan> | dminor: what happened to what used to be called the jit tests? are those now non262? |
| 20:04 | <dminor> | The jit tests are still around, we'd plan to keep those separate for now, since they're much more implementation focused. |
| 20:04 | <dminor> | The non262 tests are more general, but don't necessarily line up with test262 expectations of testing a single part of the specification at a time. |
| 20:05 | <dminor> | Or at least that's how I understand what test262 is doing. |
| 21:40 | <ljharb> | fwiw i think implementation-contributed is basically an unmaintained dump, and the new place is the staging directory |
| 21:40 | <ljharb> | even better ofc is if you can PR them with all the right boilerplate directly into the right places, but staging is so you can defer that work |
| 22:00 | <littledan> | I think the idea of staging is no longer that you are implicitly saying you will eventually do that other work, but the maintainers can clarify better than me. |
| 22:14 | <shu> | it's like "there's more value in getting everyone to run something without boilerplate today, than to not have anything until we've written the boilerplate". i don't think there's an implicit promise in commiting the staging, the promise is explicit in requiring the boilerplate and organization for Stage 4 |
| 22:16 | <shu> | (i'm assuming that stage 4 is a goal we all share. non-champion implementers who shipped a proposal should care about the spec reflecting reality asap) |
| 22:20 | <ljharb> | oh, agree |
| 22:20 | <ljharb> | i meant like, defer that work to test262 maintainers |
| 22:26 | <shu> | ah |
| 22:51 | <dminor> | Hmm, so it sounds like we'd prefer implementation-contributed to go away or at least not grow larger. I'm not sure to what extent our non262 tests are suitable for staging, the other option we've discussed is merging them into the jit tests. |
| 22:52 | <dminor> | That might be a short term solution for cleaning up our testing situation, and longer term, we can start going through tests to review what would be suitable for test262. |
| 23:10 | <ptomato> | I can go into more detail tomorrow, but I'm actually interested in refurbishing implementation-contributed and automatically syncing tests from implementations there in a way that other implementations can run them directly |