Community plans #6399
Community plans #6399
Conversation
Future Plan.md
Outdated
|
|
||
| ## Development process | ||
|
|
||
| This community development will proceed on the Chakracore master branch. At a future time this repository may be transferred out of the microsoft organisation within Github - though it will remain here to begin with. |
There was a problem hiding this comment.
@divmain Please could you confirm that having the community team begin making commits to the master branch will not cause problems for Microsoft's ongoing security fixes on the Release 1.11 branch.
There was a problem hiding this comment.
Yes, feel free to commit to master - or adopt a different branching strategy, if that makes sense for the folks involved.
Future Plan.md
Outdated
|
|
||
| ## Licensing and Copyright | ||
|
|
||
| The project will continue to be licensed under the MIT license. However the license and copyright statements will be updated to say "Copyright (c) Microsoft Corporation and Chakracore Community contributors". |
There was a problem hiding this comment.
@divmain please could you check if this is acceptable to Microsoft and/or suggest an alternative.
There was a problem hiding this comment.
That seems entirely reasonable and is in line with [this article], which provides straightforward guidelines for copyright notices in OSS projects.
Future Plan.md
Outdated
|
|
||
| ## Security Issues | ||
|
|
||
| Until March 2021 we will liaise with microsoft on any security issues in case they relate to Chakracore 1.11 and Chakra.dll - the exact method for this is to be determined. For the time being please report any Chakracore security concerns to microsoft via the microsoft security tech centre in the first instance. |
There was a problem hiding this comment.
@divmain please advise how we can best handle this point. We would also like to be informed of any security issues discovered in chakracore so we can fix them before producing a release. As well as wanting to avoid accidentally publishing any issues before microsoft has been able to fix them for Chakra.dll.
Could we have a shared (updated by both us and microsoft and reviewed by both) private list of chakracore security issues, maintained until March 2021?
There was a problem hiding this comment.
We should be able to do something here. Let me talk to some folks and get back to you.
| We will continue to use the existing check in CI for the time being. However we will aim to migrate this to a platform managed by the community team before March 2021 - we will seek Microsoft's assistance with this migration. | ||
|
|
||
| We will additionally ask Google's project OSS-Fuzz to provide continuous fuzzing for our work. |
There was a problem hiding this comment.
@divmain I assume this is acceptable for now? Please can you also confirm what level of Azure pipelines support the existing Chakracore CI uses - does it definitely fit within the free tier?
There was a problem hiding this comment.
This is absolutely acceptable - please incorporate whatever tools make your job easier. I don't have direct knowledge of ChakraCore CI usage, and whether it fits into the free tier. That's something I can check on, as well.
| 1. Review all open bug reports and assess impact, fix where practicable. | ||
|
|
||
| 1. Complete partially complete work including: | ||
|
|
There was a problem hiding this comment.
I am aware that there is also a partially complete BigInt implementation but I have no idea how far along it is - hence not put it in the list of things to complete for the first release though perhaps it could be a stretch goal?
There was a problem hiding this comment.
Found #5440. How important that is vs regex below? I can take a look into what those two things would take to do, though this does look a lower-hanging fruit. @zenparsing your input would also be appreciated :)
We don't have to sort this plan out in here, maybe should open a separate issue.
There was a problem hiding this comment.
The current BigInt implementation is not very far along - perhaps 1/3 complete. I think that the current partial implementation needs quite a bit of refactoring as well.
I think BigInt is pretty important. If we can reuse or port some existing OSS code for arbitrary precision integer arithmetic then it shouldn't be too difficult.
There was a problem hiding this comment.
I'll try to setup a periodic call between OSS contributors and former Chakra people, so that you have a medium to surface questions like this.
|
|
||
| - Implementation of Top level await | ||
|
|
||
| - RegExp ES6 properties and unicode mode |
There was a problem hiding this comment.
This one (RegEx) may be a larger piece of work BUT as far as I know it's the one major ES6 deficiency that Chakracore still has and IMO it just needs to be sorted.
There was a problem hiding this comment.
This is just a suggestion - to reduce scope of the changes before release, I'd consider regex "extra credit" - if we make it it would be great, but if that turns out to be lots of work, then it can go into the next release. I am fine either way - I don't understand full technical scope, but it looks like we need to review compliance.
There was a problem hiding this comment.
There's 3 parts RegEx Symbols, RegEx prototype properties AND RegEx unicode mode matching.
The first two have implementations behind features flags - I think they're 90% done, need testing, a little fixing and enabling. The third one - unicode mode matching is not done at all - the unicode flag is used for how the RegEx is parsed but the matcher seems to ignore.
I agree it may be a large piece of work - I just really don't like that it's 2020 and there's some ES6 work that's unfinished.
There was a problem hiding this comment.
I’ll do some exploratory work on this later today to asses it further.
|
|
||
| We would therefore like our first release to be done fairly quickly - however there are also some half complete pieces of work to finish before that as well as a variety of bugs introduced that should be fixed before that. | ||
|
|
||
| We will aim to do this first release by June to allow time for confirming the exact status of the project, completing unfinished work, performing testing and fixing bugs. |
There was a problem hiding this comment.
In a way I'd like to say End of April - but I don't think that's feasible, unless we could have one or two people full time. Anyone else's thoughts here appreciated.
There was a problem hiding this comment.
Agreed. I think June is a good goal for now.
|
|
||
| 1. Have Google OSS-Fuzz recommence fuzzing of the master branch and triage the first reports from them. | ||
|
|
||
| 1. Determine release method - where will releases be posted? Who will post them? How will it be clear that this release is NOT supported by microsoft? |
There was a problem hiding this comment.
@divmain will likely need your input on this.
There was a problem hiding this comment.
There are a few options here. If the repository is moved to a new org, that will help to elucidate Microsoft's involvement in future releases.
As far as publishing to NuGet... I don't have an answer, and I need to talk to some security folks here. It is possible there will be discomfort handing over the credentials for NuGet publishing, since it is theoretically possible for a patch release to be generated and pulled into projects automatically (opening security issue for current users).
You may need to publish to NuGet under an alternate name, assuming this is still of interest to you.
There was a problem hiding this comment.
I think we definitely want to transfer the repository to a new org in the future - however I'd assumed that doing that before Microsoft stops making security updates to 1.11 could be a problem? We could just work on a fork but I'd rather transfer the actual repository if we're allowed to.
As for releasing on NuGet under a different name - if that's the only option we may have to go with it, though Ideally we'd want a name that makes clear this is still fundamentally the same product just with different maintainers.
Future Plan.md
Outdated
|
|
||
| Future releases of Chakracore are planned by a community team of volunteers (please see history section at the end of this document for how this has come about). We will aim to: | ||
|
|
||
| 1. Prioritise ease of use for potential embedders of chakracore - these are intended as our primary users. We will aim to reflect this priority in any design decisions and by committing to never breaking the API and providing detailed and user friendly documentation. |
There was a problem hiding this comment.
never breaking the API
This is nearly impossible IMO.
I think we can try to resume Node ChakraCore releases maybe, but not sure how hard it is to maintain a compatibility layer.
There was a problem hiding this comment.
With the API, I'm referring to the Chakracore external API - it's been largely frozen for several years apart from adding extra functions, nothing has been removed and no functionality broken (that I've noticed) since one API (JsCopyString) was altered in version 1.7.
We could tone down or slightly change the message here - however for any potential users having a stable API is a massive boon.
There was a problem hiding this comment.
We could tone down or slightly change the message here - however for any potential users having a stable API is a massive boon.
I agree on toning it down a bit, but prioritizing stability and ease of embedding sound like a good move.
I think we can try to resume Node ChakraCore releases maybe, but not sure how hard it is to maintain a compatibility layer.
To me that sounds like a good idea. nodejs/node-chakracore has been archived, so we might need to restart that somehow - I don't know if repos can be un-archived. Not sure if we want to commit to that in the plan.
Difficulty depends on how far out of date chakrashim is.
There was a problem hiding this comment.
I don't know if repos can be un-archived.
I just checked, they can be unarchieved via settings
There was a problem hiding this comment.
Rebooting node-chakracore would be cool, though may be a bit of work - and also feels like a bit of a seperate direction to the initial goal of maintaining chakracore - whilst the last version of it should run if we just drop in a newer version of chakracore; dropping in a newer version of node will be more difficult due to changes in the v8 API and I think newer node needs some newer JS features e.g. BigInt that aren't fully implemented in chakracore yet.
There was a problem hiding this comment.
node-chakracore could became a good PoC embedder. Potentially we can team up with Node team. They also have CI/CD set up.
There was a problem hiding this comment.
A few months ago I took a look into updating node-chakracore - it was not trivial. I agree that it would be great for CC to have a "PoC" embedder but I don't think that node is a good choice - there's practically zero incentive for someone to choose node-cc if they want to use node.
Now, a fresh take on a JS environment could be interesting!
There was a problem hiding this comment.
Assuming we could update it, the problem of node-CC as a POC for embedding CC is that it largely works by shimming v8 on top of CC then embedding v8. So it doesn't show what a "normal" CC based environment should look like.
That said I'd be keen on reviving it anyway - though not before we have a new CC release out. I'd also be keen on making a more fully featured CC host as a PoC for others - again not as the top priority though.
On a related note, my friend @fatcerberus has a game engine https://github.com/fatcerberus/minisphere/ that embeds CC and in some ways works as a nice POC though it could do with some planned re-working being done to make it a better POC. It currently shims a duktape inspired stack-based interface on top of ChakraCore which it then uses for most of what it does, I've been meaning to strip that shim away for him at some point so that it uses CC in a more direct way, but I haven't got around to that yet.
Future Plan.md
Outdated
|
|
||
| We will also aim to triage and address bug reports as received, depending on the scale of these issues they may be fixed immediately or left until a future release. | ||
|
|
||
| Pull requests will be invited from anyone who wishes to contribute in addition to the Core Community Team. Any pull request will be required to pass all CI checks and be reviewed by a member of the Core Community Team (different to its author) prior to being merged. The reviewer will merge the PR when happy with it - no PR should be merged by its author. |
There was a problem hiding this comment.
I think it might be OK to let community team members merge their own PRs, as long as they have approval from another team member. What do you think?
There was a problem hiding this comment.
Edited to say any CCT member can merge a PR after author and reviewer are happy.
|
|
||
| We would therefore like our first release to be done fairly quickly - however there are also some half complete pieces of work to finish before that as well as a variety of bugs introduced that should be fixed before that. | ||
|
|
||
| We will aim to do this first release by June to allow time for confirming the exact status of the project, completing unfinished work, performing testing and fixing bugs. |
There was a problem hiding this comment.
Agreed. I think June is a good goal for now.
| 1. Review all open bug reports and assess impact, fix where practicable. | ||
|
|
||
| 1. Complete partially complete work including: | ||
|
|
There was a problem hiding this comment.
The current BigInt implementation is not very far along - perhaps 1/3 complete. I think that the current partial implementation needs quite a bit of refactoring as well.
I think BigInt is pretty important. If we can reuse or port some existing OSS code for arbitrary precision integer arithmetic then it shouldn't be too difficult.
Future Plan.md
Outdated
|
|
||
| 1. Invite community involvement - this project is being continued by volunteers and input will be appreciated from any other volunteers with relevant skills and availability. We will aim to make the project easy to get involved in - if as a potential contributor you see any obvious barriers to entry please raise an issue to discuss them. | ||
|
|
||
| 1. Simplify the codebase and test suite - when time permits and where practicable we will endeavour to perform housekeeping actions such as removing dead code, combining related tests and removing unnecessary layering. |
|
|
||
| Future releases of ChakraCore are planned by a community team of volunteers (please see history section at the end of this document for how this has come about). We will aim to: | ||
|
|
||
| 1. Prioritise ease of use for potential embedders of ChakraCore - these are intended as our primary users. We will aim to reflect this priority in any design decisions including by prioritising API stability and providing detailed and user friendly documentation. |
|
Something I forgot to bring up. Do we need a separate github organization for the time after Microsoft contributions end? To me it sounds reasonable, but I would like to see what everybody thinks and whether @divmain thinks we should eventually "move out" :) If we do, we should probably start working on creating the org and moving code and so on. We don't have to decide on this right now though. |
|
Updated for various suggestions above, note the CI fail is because it doesn't like having spaces in file names, but, I think if I rename the files I'll lose the locations of comments above - so going to do that as the last step when 100% happy on other points.
I mentioned this at the start of the Development Process section, though left it as a possibility. |
|
Picking up on the API discussion above - there were several APIs added for use in node-chakracore by this PR #5923 - some of these are undocumented AND don't seem to be inline with the design style of the rest of the API - including JsObjectDefinePropertyFull which duplicates the functionality of JsObjectDefineProperty though combines the creation of the property descriptor into it. JsGetArrayKeysFunction and equivalents which provide access to specific internal library methods, not a complete set, just the ones that node-chakracore wanted at the time. Whilst I've said we should commit to API stability, these are (relatively) new, only in master AND seem out of kilter with the rest of the API which focusses on being lean, a small number of highly versatile methods rather than lots of narrow ones. I think we should potentially review/remove some of these prior to release. E.g. if we want an API for getting library methods it should be a single versatile one that can get any library method perhaps with an enormous enum for specifying which one you want rather than an API per method. |
|
Sorry for the delay - will review this tomorrow! |
|
@ppenzin - as @rhuanjl mentioned, there will be a need to move out of the MSFT GitHub org eventually. The timing is largely dependent on your needs: for example, it may be easier to manage contributions, CI, and releases if you have full control over the org. Additionally, if it would be helpful to be plugged into TC39 (@chicoxyzzy @rhuanjl or others), that may be something I can help facilitate. Let me know if there is interest, and we can have an offline discussion to explore further. |
|
@divmain can you elaborate what do you mean by "plugged into TC39"? |
|
Closing this in favour of #6442 |
Draft basic community planning documents for chakracore as a pull request to enable easy review/consideration.
@divmain please could you review for microsoft impact/approval.
@zenparsing @chicoxyzzy @Fly-Style @ppenzin please all take a look when you can.