admin
admin copied to clipboard
Transfer BOB streams repo to nodejs org
I hope this is the correct issue tracker for this.
I propose we move https://github.com/Fishrock123/bob into the nodejs
github org under a more appropriate name.
"Future Streams (BOB)", maybe.
This should be done to help prevent that work from being lost/forgotten, as it is very hard to progress alone, and my primary projects presently do not relate to node.
The project is licensed under MIT (though I wish I'd put it under dual with BlueOak before any contributions were made), and has the DCO-1.1 in it's contributing document.
There are also a handful of related repos and npm modules:
- The status codes enum: bob-status (npm)
- A file system source: fs-source (npm)
- A file system sink: fs-sink (npm)
- A zlib transform: zlib-transform (npm)
- A crc32 transform: crc-transform (npm)
- Header for the C++ api: bob-base (npm)
I believe all of those are also MIT & DCO-1.1, and I'm not quite sure what to do with them, considering the "main" repo kinda depends on / tests them.
An alternate approach could be to stuff those additional modules all under a separate github org, I suppose.
cc @mcollina, @jasnell, @raynos
Hi, @Fishrock123! The procedure is detailed in https://github.com/nodejs/admin/blob/master/transfer-repo-into-the-org.md. Only thing I'm seeing missing in the repo is a code of conduct (which, if you wish, can just be a single sentence saying that the project uses the Node.js Code of Conduct and providing a link to https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md).
Other than that, this seems good to me.
LGTM/+1
SGTM
+1
The repo should get a code of conduct added before being transferred. Other than that, it seems ready.
+1 once code of conduct is added.
Have you guys seen https://github.com/callbag/callbag?
It seems to provide an extremely flexible API for similar functionality as some kind of a standard. "Not a library, just a standard (...)"
Just curious here, what's the status/plan for this?
Still undermined but we should discuss at the tsc meeting. Fwiw, I've incorporated a modified version of the c/c++ API into the quic implementation but we still need to decide overall direction here
At this point the lack of interest here now makes me very hesitant to actually do this, since it is essentially 95?% my work still. (I don't think I've done anything to complicate contributions, though?)
There does seem to be a lack of overall interest but, fwiw, I am using a variation on the c++ API in the quic implementation.