-
Notifications
You must be signed in to change notification settings - Fork 97
Conversation
additionally, almost all of the links point to the current website right now. how big of a priority should a new website be? |
README.md
Outdated
@@ -464,7 +446,7 @@ maintaining the Node.js project. | |||
|
|||
### Release Team | |||
|
|||
Node.js releases are signed with one of the following GPG keys: | |||
Ayo.js releases are signed with one of the following GPG keys: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think this is very accurate :) How about just replacing are signed
→ were signed
for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
additionally, almost all of the links point to the current website right now. how big of a priority should a new website be?
I'd say not a priority at all, right now.
README.md
Outdated
@@ -464,7 +446,7 @@ maintaining the Node.js project. | |||
|
|||
### Release Team | |||
|
|||
Node.js releases are signed with one of the following GPG keys: | |||
Ayo.js releases were signed with one of the following GPG keys: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They never were. I think we should get rid of this section or say "Ayo.js is forked from Node.js, and their releases were signed with..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realise that this PR is currently a find and replace, but I think my above comment is worth doing now.
README.md
Outdated
@@ -509,7 +491,7 @@ Previous releases may also have been signed with one of the following GPG keys: | |||
|
|||
### Working Groups | |||
|
|||
Information on the current Node.js Working Groups can be found in the | |||
Information on the current Ayo.js Working Groups can be found in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, they can't. Because we don't have any yet. :) I'd remove the section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I realise that this PR is currently a find and replace, but I think my above comment is worth doing now.
@@ -175,7 +157,7 @@ handling your report. | |||
|
|||
## Current Project Team Members |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we scrap this list?
I'm gonna stop commenting now, but I say we Remove text from all of the subheadings we haven't dealt with (most of them) and Put a "to be written" under each. Otherwise this PR will be open forever and I'm a big fan of small iterations. |
@varjmes done! |
By the way, if we want to stick to a release process similar to that of Node, it would be not mandatory but helpful if we kept its commit metadata rules to some degree Not saying we have to :) |
@addaleax you mean squashing PRs? i have no idea how it works in node core, to be honest |
When we merge PR we add metadata in the style of what you see in nodejs/node@6a0e3b1 (PR-URL: is the full URL, not just the #, github just doesn’t display it) In particular, PR-URL is required by the current tooling for making releases/updating branches |
oh, okay! should we squash/reword the commits that are now on master, then? |
I would suggest doing that until we agree that we want some other kind of format :) (There’s even tooling like https://github.com/evanlucas/core-validate-commit for checking that data) |
@pup regarding the metadata, basically, what Anna said, but I'd add there is some documentation about it (https://github.com/ayojs/ayo/blob/master/COLLABORATOR_GUIDE.md#landing-pull-requests) that describes both these policies and some related Git recipes which might be helpful :) Speaking about whether these guidelines should be changed, both leaving and omitting the |
I'd say this repository is currently in position where doing |
@aqrln Yeah, totally agree, esp with 0 open PRs. :) I can do that if nobody else is feeling like it. |
i would greatly appreciate someone else doing it, so I can take note :) |
PR-URL: #1 Reviewed-By: Anna Henningsen <anna@addaleax.net>
Currently when running the test without an internet connection there are two JavaScript test failures and one cctest. The cctest only fails on Mac as far as I know. (I've only tested using Mac and Linux thus far). This commit moves the two JavaScript tests to test/internet. The details for test_inspector_socket_server.cc: [ RUN ] InspectorSocketServerTest.FailsToBindToNodejsHost make[1]: *** [cctest] Segmentation fault: 11 make: *** [test] Error 2 lldb output: [ RUN ] InspectorSocketServerTest.FailsToBindToNodejsHost Process 63058 stopped * thread #1: tid = 0x7b175, 0x00007fff96d04384 * libsystem_info.dylib`_gai_simple + 87, queue = * 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, * address=0x0) frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87 libsystem_info.dylib`_gai_simple: -> 0x7fff96d04384 <+87>: movw (%rdx), %ax 0x7fff96d04387 <+90>: movw %ax, -0x2a(%rbp) 0x7fff96d0438b <+94>: movq %r13, -0x38(%rbp) 0x7fff96d0438f <+98>: movq 0x18(%rbp), %rcx (lldb) bt * thread #1: tid = 0x7b175, 0x00007fff96d04384 * libsystem_info.dylib`_gai_simple + 87, queue = * 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, * address=0x0) * frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87 frame #1: 0x00007fff96cfe98b libsystem_info.dylib`search_addrinfo + 179 frame #2: 0x00007fff96cfafef libsystem_info.dylib`si_addrinfo + 2255 frame #3: 0x00007fff96cfa67b libsystem_info.dylib`getaddrinfo + 179 frame #4: 0x00000001017d8888 cctest`uv__getaddrinfo_work(w=0x00007fff5fbfe210) + 72 at getaddrinfo.c:102 frame #5: 0x00000001017d880e cctest`uv_getaddrinfo(loop=0x000000010287cb80, req=0x00007fff5fbfe1c8, cb=0x0000000000000000, hostname="nodejs.org", service="0", hints=0x00007fff5fbfe268) + 734 at getaddrinfo.c:192 frame #6: 0x000000010171f781 cctest`node::inspector::InspectorSocketServer::Start(this=0x00007fff5fbfe658) + 801 at inspector_socket_server.cc:398 frame #7: 0x00000001016ed590 cctest`InspectorSocketServerTest_FailsToBindToNodejsHost_Test::TestBody(this=0x0000000105001fd0) + 288 at test_inspector_socket_server.cc:593 I'm not sure about the exact cause for this but when using a standalone c program to simulate this it seems like when the ai_flags `AI_NUMERICSERV` is set, which is done in inspector_socket_server.cc line 394, the servname (the port in the FailsToBindToNodejsHost test) is expected to be a numeric port string to avoid looking it up in /etc/services. When the port is 0 as is it was before this commit the segment fault occurs but not if it is non-zero. PR-URL: nodejs/node#16255 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
Currently when running the test without an internet connection there are two JavaScript test failures and one cctest. The cctest only fails on Mac as far as I know. (I've only tested using Mac and Linux thus far). This commit moves the two JavaScript tests to test/internet. The details for test_inspector_socket_server.cc: [ RUN ] InspectorSocketServerTest.FailsToBindToNodejsHost make[1]: *** [cctest] Segmentation fault: 11 make: *** [test] Error 2 lldb output: [ RUN ] InspectorSocketServerTest.FailsToBindToNodejsHost Process 63058 stopped * thread #1: tid = 0x7b175, 0x00007fff96d04384 * libsystem_info.dylib`_gai_simple + 87, queue = * 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, * address=0x0) frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87 libsystem_info.dylib`_gai_simple: -> 0x7fff96d04384 <+87>: movw (%rdx), %ax 0x7fff96d04387 <+90>: movw %ax, -0x2a(%rbp) 0x7fff96d0438b <+94>: movq %r13, -0x38(%rbp) 0x7fff96d0438f <+98>: movq 0x18(%rbp), %rcx (lldb) bt * thread #1: tid = 0x7b175, 0x00007fff96d04384 * libsystem_info.dylib`_gai_simple + 87, queue = * 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, * address=0x0) * frame #0: 0x00007fff96d04384 libsystem_info.dylib`_gai_simple + 87 frame #1: 0x00007fff96cfe98b libsystem_info.dylib`search_addrinfo + 179 frame #2: 0x00007fff96cfafef libsystem_info.dylib`si_addrinfo + 2255 frame #3: 0x00007fff96cfa67b libsystem_info.dylib`getaddrinfo + 179 frame #4: 0x00000001017d8888 cctest`uv__getaddrinfo_work(w=0x00007fff5fbfe210) + 72 at getaddrinfo.c:102 frame #5: 0x00000001017d880e cctest`uv_getaddrinfo(loop=0x000000010287cb80, req=0x00007fff5fbfe1c8, cb=0x0000000000000000, hostname="nodejs.org", service="0", hints=0x00007fff5fbfe268) + 734 at getaddrinfo.c:192 frame #6: 0x000000010171f781 cctest`node::inspector::InspectorSocketServer::Start(this=0x00007fff5fbfe658) + 801 at inspector_socket_server.cc:398 frame #7: 0x00000001016ed590 cctest`InspectorSocketServerTest_FailsToBindToNodejsHost_Test::TestBody(this=0x0000000105001fd0) + 288 at test_inspector_socket_server.cc:593 I'm not sure about the exact cause for this but when using a standalone c program to simulate this it seems like when the ai_flags `AI_NUMERICSERV` is set, which is done in inspector_socket_server.cc line 394, the servname (the port in the FailsToBindToNodejsHost test) is expected to be a numeric port string to avoid looking it up in /etc/services. When the port is 0 as is it was before this commit the segment fault occurs but not if it is non-zero. PR-URL: nodejs/node#16255 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
this is a very rough edit that, for now, mainly just replaces all instances of
Node.js
withAyo.js
in the README file. obviously, most of the readme is broken right now, so this PR can serve as a general place to refactor the readme as far as we can.another alternative would be to just drop the current readme altogether and draft a new one. what does everyone think?