Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Miscellaneous python3-related updates and fixes #20856

Merged
merged 14 commits into from Jul 10, 2020

Conversation

DeeDeeG
Copy link
Contributor

@DeeDeeG DeeDeeG commented May 30, 2020

Requirements for Adding, Changing, or Removing a Feature

Issue or RFC Endorsed by Atom's Maintainers

Last bits of #20585 (see this comment for details.)

Description of the Change

  • [Code change] Updated the verifyPython() function in script/lib/verify-machine-requirements.js
    • Can find Python 3 now
    • Works (and is now set to run) on all platforms, not just Windows
    • Closely matches node-gyp's find-python.js library's behavior, so that we get an accurate indication that native packages can actually be built (this is the only reason Python is used or needed).
  • 馃敟 Deleted .python-version
  • 馃敟 Deleted lintian overrides metadata, since this wasn't being used and is cruft.
  • 馃摑 Updated README.md to mention installing python3, not python
    • Explains you can still use python or python2 if python3 doesn't work.
  • [CI] Update the windows CI test environment to use Python 3 instead of Python 2.

Alternate Designs

For verifyPython(), it could be good to think of a way to actually run node-gyp rebuild or otherwise have node-gyp find Python for us. I haven't thought of a way to do this that actually works.

(I tried using node-gyp's find-python.js directly, but it made the bootstrap script execute out of order: The verify Python check only ran AFTER the boostrap script finished, so I gave up. This is something to do with the nature of async JavaScript code.)

The re-write I did for verifyPython() is synchronous enough to work as intended. It could be re-written to be more async by a more-skilled JavaScript programmer, but this is a bootstrap script, not production code, so not blocking the main thread during execution is pretty much a non-issue, and it still finishes in about a second even on an old Windows laptop.

Possible Drawbacks

I have thoroughly tested these changes, so I hope there are no issues I've overlooked.

Verification Process

Tested and tested and re-tested verifyPython() on Linux and Windows. macOS is expected to behave the same as Linux with respect to locating Python. (Indeed, Linux and macOS are handled the same in node-gyp, which is what this implementation is based on.)

Checked the behavior with/without pyenv and with/without the .python-version file. All seems to work as intended, and it's much more flexible without a .python-version file checked in.

The rest is deleting cruft (lintian metadata) or updating documentation (README.md). I proofread my changes to README.md 馃槃.

Release Notes

N/A (not user-facing. These are developer-oriented changes.)


View rendered README.md

DeeDeeG added 7 commits May 30, 2020
We support Python 3 now. Use that in the default instructions,
but explain that `python2` or `python` will work in its place.
These overrides are very outdated.
(Haven't been updated since the day they were added, back in 2014.)
Even with these applied, Lintian still prints many warns/errors.

I think no-one has been running Lintian
against the .deb package for a while now.
Use this to find python for the verify-machine-requirements.js script.
.python-version specifies which version(s) of Python are in the PATH,
and which version runs when you run the python, python2, or python3
commands.

That said, it is overly specific for this repository's needs.
In order to specify any version, you must enter it down to the patch
level, e.g. 3.8.2; Major-minor versions aren't allowed, e.g. 2.7

If users want to add such a file on their own machines, they may...
But it's unneccesary for this repository to ship this file as if there
were specific "correct" versions of Python to use.

Any Python 2.7.x or 3.5.0+ will work at the moment.

There are other checks elsewhere in the project, such as in
script/bootstrap. These should be sufficient to inform users which
Python versions they can use. node-gyp will also tell you.
Log which Python commands were tried, and the results,
if no usable Python was found. Useful for debugging failures.
Python 2 is officially end-of-life. We can use Python 3 now.
@DeeDeeG

This comment has been minimized.

@DeeDeeG

This comment has been minimized.

in script/lib/verify-machine-requirements.js
@DeeDeeG

This comment has been minimized.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jun 3, 2020

Note on "alternative designs": This PR could drop a lot of complexity if we don't perform any check for Python at all in the boostrap process. Meaning node-gyp would handle finding Python for us, and if there is no usable Python, node-gyp's error will be shown.

The only downside I can think of is that node-gyp's error messages are SO DETAILED that they can be intimidating, and it might not be obvious at a glance that the error says you need a different Python on your system.

Example `node-gyp` error for not being able to find Python (click to expand):
user@host:~/atom$ script/bootstrap
Node:	v12.18.0
Npm:	v6.14.4
Installing script dependencies
gyp ERR! find Python 
gyp ERR! find Python Python is not set from command line or npm configuration
gyp ERR! find Python Python is not set from environment variable PYTHON
gyp ERR! find Python checking if "python" can be used
gyp ERR! find Python - executable path is "/usr/bin/python"
gyp ERR! find Python - version is "3.4.3"
gyp ERR! find Python - version is 3.4.3 - should be ^2.6.0 || >=3.5.0
gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED
gyp ERR! find Python checking if "python2" can be used
gyp ERR! find Python - "python2" is not in PATH or produced an error
gyp ERR! find Python checking if "python3" can be used
gyp ERR! find Python - "python3" is not in PATH or produced an error
gyp ERR! find Python 
gyp ERR! find Python **********************************************************
gyp ERR! find Python You need to install the latest version of Python.
gyp ERR! find Python Node-gyp should be able to find and use Python. If not,
gyp ERR! find Python you can try one of the following options:
gyp ERR! find Python - Use the switch --python="/path/to/pythonexecutable"
gyp ERR! find Python   (accepted by both node-gyp and npm)
gyp ERR! find Python - Set the environment variable PYTHON
gyp ERR! find Python - Set the npm configuration variable python:
gyp ERR! find Python   npm config set python "/path/to/pythonexecutable"
gyp ERR! find Python For more information consult the documentation at:
gyp ERR! find Python https://github.com/nodejs/node-gyp#installation
gyp ERR! find Python **********************************************************
gyp ERR! find Python 
gyp ERR! configure error 
gyp ERR! stack Error: Could not find any Python installation to use
gyp ERR! stack     at PythonFinder.fail (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:307:47)
gyp ERR! stack     at PythonFinder.runChecks (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:136:21)
gyp ERR! stack     at PythonFinder.<anonymous> (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:179:16)
gyp ERR! stack     at PythonFinder.execFileCallback (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:271:16)
gyp ERR! stack     at exithandler (child_process.js:310:5)
gyp ERR! stack     at ChildProcess.errorhandler (child_process.js:322:5)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
gyp ERR! stack     at onErrorNT (internal/child_process.js:469:16)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:84:21)
gyp ERR! System Linux 5.4.0-33-generic
gyp ERR! command "/home/[user]/n-prefix/bin/node" "/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/[user]/atom/script/node_modules/minidump
gyp ERR! node -v v12.18.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok 
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! minidump@0.9.0 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the minidump@0.9.0 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/[user]/.npm/_logs/2020-06-03T20_01_19_428Z-debug.log
child_process.js:651
    throw err;
    ^

Error: Command failed: npm --loglevel=error install
gyp ERR! find Python 
gyp ERR! find Python Python is not set from command line or npm configuration
gyp ERR! find Python Python is not set from environment variable PYTHON
gyp ERR! find Python checking if "python" can be used
gyp ERR! find Python - executable path is "/usr/bin/python"
gyp ERR! find Python - version is "3.4.3"
gyp ERR! find Python - version is 3.4.3 - should be ^2.6.0 || >=3.5.0
gyp ERR! find Python - THIS VERSION OF PYTHON IS NOT SUPPORTED
gyp ERR! find Python checking if "python2" can be used
gyp ERR! find Python - "python2" is not in PATH or produced an error
gyp ERR! find Python checking if "python3" can be used
gyp ERR! find Python - "python3" is not in PATH or produced an error
gyp ERR! find Python 
gyp ERR! find Python **********************************************************
gyp ERR! find Python You need to install the latest version of Python.
gyp ERR! find Python Node-gyp should be able to find and use Python. If not,
gyp ERR! find Python you can try one of the following options:
gyp ERR! find Python - Use the switch --python="/path/to/pythonexecutable"
gyp ERR! find Python   (accepted by both node-gyp and npm)
gyp ERR! find Python - Set the environment variable PYTHON
gyp ERR! find Python - Set the npm configuration variable python:
gyp ERR! find Python   npm config set python "/path/to/pythonexecutable"
gyp ERR! find Python For more information consult the documentation at:
gyp ERR! find Python https://github.com/nodejs/node-gyp#installation
gyp ERR! find Python **********************************************************
gyp ERR! find Python 
gyp ERR! configure error 
gyp ERR! stack Error: Could not find any Python installation to use
gyp ERR! stack     at PythonFinder.fail (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:307:47)
gyp ERR! stack     at PythonFinder.runChecks (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:136:21)
gyp ERR! stack     at PythonFinder.<anonymous> (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:179:16)
gyp ERR! stack     at PythonFinder.execFileCallback (/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/lib/find-python.js:271:16)
gyp ERR! stack     at exithandler (child_process.js:310:5)
gyp ERR! stack     at ChildProcess.errorhandler (child_process.js:322:5)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:273:12)
gyp ERR! stack     at onErrorNT (internal/child_process.js:469:16)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:84:21)
gyp ERR! System Linux 5.4.0-33-generic
gyp ERR! command "/home/[user]/n-prefix/bin/node" "/home/[user]/n-prefix/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/[user]/atom/script/node_modules/minidump
gyp ERR! node -v v12.18.0
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok 
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! minidump@0.9.0 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the minidump@0.9.0 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/[user]/.npm/_logs/2020-06-03T20_01_19_428Z-debug.log

    at checkExecSyncError (child_process.js:630:11)
    at Object.execFileSync (child_process.js:648:15)
    at module.exports (/home/[user]/atom/script/lib/install-script-dependencies.js:9:16)
    at Object.<anonymous> (/home/[user]/atom/script/bootstrap:37:1)
    at Module._compile (internal/modules/cjs/loader.js:1138:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
    at Module.load (internal/modules/cjs/loader.js:986:32)
    at Function.Module._load (internal/modules/cjs/loader.js:879:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47 {
  status: 1,
  signal: null,
  output: [
    null,
    <Buffer 0a 3e 20 6c 65 76 65 6c 64 6f 77 6e 40 35 2e 34 2e 31 20 69 6e 73 74 61 6c 6c 20 2f 68 6f 6d 65 2f 6d 61 74 65 2f 61 74 6f 6d 2f 73 63 72 69 70 74 2f ... 502 more bytes>,
    <Buffer 67 79 70 20 45 52 52 21 20 66 69 6e 64 20 50 79 74 68 6f 6e 20 0a 67 79 70 20 45 52 52 21 20 66 69 6e 64 20 50 79 74 68 6f 6e 20 50 79 74 68 6f 6e 20 ... 3339 more bytes>
  ],
  pid: 33850,
  stdout: <Buffer 0a 3e 20 6c 65 76 65 6c 64 6f 77 6e 40 35 2e 34 2e 31 20 69 6e 73 74 61 6c 6c 20 2f 68 6f 6d 65 2f 6d 61 74 65 2f 61 74 6f 6d 2f 73 63 72 69 70 74 2f ... 502 more bytes>,
  stderr: <Buffer 67 79 70 20 45 52 52 21 20 66 69 6e 64 20 50 79 74 68 6f 6e 20 0a 67 79 70 20 45 52 52 21 20 66 69 6e 64 20 50 79 74 68 6f 6e 20 50 79 74 68 6f 6e 20 ... 3339 more bytes>
}
Example error from `verifyPython()` that I wrote for this PR (click to expand):
user@host:~/atom$ script/bootstrap
Node:	v12.18.0
Npm:	v6.14.4
/home/[user]/atom/script/lib/verify-machine-requirements.js:161
    throw new Error(
    ^

Error: 
log message: tried to check version of "python", got: "3.4.3"
log message: tried to check version of "python2", got: ""
log message: tried to check version of "python3", got: ""

Python 2.7 or 3.5+ is required to build Atom.
verify-machine-requirements.js was unable to find such a version of Python.
Set the PYTHON env var to e.g. 'C:/path/to/Python27/python.exe'
if your Python is installed in a non-default location.

    at verifyPython (/home/[user]/atom/script/lib/verify-machine-requirements.js:161:11)
    at module.exports (/home/[user]/atom/script/lib/verify-machine-requirements.js:11:3)
    at Object.<anonymous> (/home/[user]/atom/script/bootstrap:29:1)
    at Module._compile (internal/modules/cjs/loader.js:1138:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1158:10)
    at Module.load (internal/modules/cjs/loader.js:986:32)
    at Function.Module._load (internal/modules/cjs/loader.js:879:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at internal/main/run_main_module.js:17:47

DeeDeeG added 3 commits Jun 3, 2020
Make sure a previously found version isn't erroneously logged,
by clearing the "fullVersion" variable before each new check.
@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jun 5, 2020

I do have an implementation working where our verifyPython() function uses the node-gyp module's lib/find-python.js directly. It turns out not to be a very small change to the repo to do this, at least with the best implementation I have thought of at the moment. Nevertheless, if anyone is curious how it looks, I can try to polish it up and then post a link to the branch.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jun 30, 2020

I plan to close this soon if there is no comment from maintainers. Thanks for merging the previous Python fixes.

These small changes are nice-to-haves, not big important things.

cc @lkashef in case you didn't see this PR before.

@aminya
Copy link
Contributor

aminya commented Jul 1, 2020

I plan to close this soon if there is no comment from maintainers. Thanks for merging the previous Python fixes.

These small changes are nice-to-haves, not big important things.

Please don't close this if they are relevant. Hopefully, someday, one of us will get access to the Atom repository and can review and merge all of these. I have already sent emails, but no luck yet.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jul 1, 2020

Just trying to strike a balance between giving the current maintainers too much to review, or too much bandwidth of communication, vs what time they can spend on this. (The list of PRs is considered a backlog/to-do list apparently.)

I might also like to volunteer as an outside collaborator. Until then I try to work on things as just any regular GitHub user.

But yeah, in hindsight this PR is how I would propose to address the last bits of the Python 3 stuff if anyone ever got around to discuss/review and merge. No sense closing it just to have to post a new PR again some time down the line. So I won't close it.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jul 1, 2020

Off-topic: If you want to start a fork of Atom based around moving faster on backlog/to-do items here at the main repo, I could pitch in some effort. And I would want to work closely with upstream to the extent possible, upstreaming changes and stuff. This is open-source, after all.

@aminya
Copy link
Contributor

aminya commented Jul 2, 2020

If you want to start a fork of Atom based around moving faster

@DeeDeeG That's a very good idea! We can create a parallel repository of Atom in the atom-ide-community organization and call it atom-community, and really change things! Then we can release the builds under the atom-community name.

I am already a member of the organization. Once I get owner access, I will invite you, so we can start!
https://twitter.com/AminYa74/status/1278682555395584001

@lkashef
Copy link
Contributor

lkashef commented Jul 2, 2020

@DeeDeeG Thanks for the contribution 馃檱鈥嶁檪锔 this is pretty helpful actually!

I am re-running the CI to make sure we didn't miss anything


Thanks @DeeDeeG and @aminya for the great collaboration.

As we treat the open issues and PR as our backlog, keeping them open keeps it under our radar, sometimes priority changes but your contributions are always helpful and will eventually be addressed by the team.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jul 2, 2020

Thank you @lkashef for taking a look at this.


Off-topic again, if the fork gets going: @aminya my thoughts are to keep a branch at the fork exactly in-sync with upstream master (call itupstream, upstream-master, master, whatever) and we have another branch that's the default for the fork (call it fork or community, or develop, whatever).

My thoughts on priorities are actually just to look at the backlog of PRs here and try them out and merge them if we can get them working. And try to update Electron until we get to a supported version (one major version at a time, so upstream can feel confident in the process and results, and so our work doesn't become un-mergeable to upstream). 'd also like to look through documentation and update the out-of-date stuff. The whole thing doesn't really make sense if upstream maintainers are fast enough, because then you'd want to work directly in the upstream repo, but that's the point, shake things up with action not just words. Encourage faster movement by example.

I have no personal interest in moving beyond that to feature changes or arbitrary tweaks, but that's just my opinion, and I'd be open to it diverging if we can stay helpful to upstream and still propose simple PRs to upstream as much as possible.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jul 2, 2020

@lkashef I'm not sure why the "package tests" on macOS failed this time (CI).

@lkashef
Copy link
Contributor

lkashef commented Jul 3, 2020

@DeeDeeG looks like a flaky test, I am re-running the CI again

DeeDeeG added a commit to DeeDeeG/flight-manual.atom.io that referenced this pull request Jul 9, 2020
Python 3 will be supported on Windows when atom/atom#20856
or similar gets merged into the atom repository.
@lkashef lkashef merged commit d840b89 into atom:master Jul 10, 2020
1 check passed
@lkashef
Copy link
Contributor

lkashef commented Jul 10, 2020

Thank you @lkashef for taking a look at this.

Off-topic again, if the fork gets going: @aminya my thoughts are to keep a branch at the fork exactly in-sync with upstream master (call itupstream, upstream-master, master, whatever) and we have another branch that's the default for the fork (call it fork or community, or develop, whatever).

My thoughts on priorities are actually just to look at the backlog of PRs here and try them out and merge them if we can get them working. And try to update Electron until we get to a supported version (one major version at a time, so upstream can feel confident in the process and results, and so our work doesn't become un-mergeable to upstream). 'd also like to look through documentation and update the out-of-date stuff. The whole thing doesn't really make sense if upstream maintainers are fast enough, because then you'd want to work directly in the upstream repo, but that's the point, shake things up with action not just words. Encourage faster movement by example.

I have no personal interest in moving beyond that to feature changes or arbitrary tweaks, but that's just my opinion, and I'd be open to it diverging if we can stay helpful to upstream and still propose simple PRs to upstream as much as possible.

Hi @DeeDeeG, sorry never go to share my thoughts on the above comment properly.

The idea sounds really great, I love the direction you are taking, specially that part "I have no personal interest in moving beyond that to feature changes or arbitrary tweaks" and I am sure it will help move core improvements like this faster.

I would also recommend joining Atom Slack so it would be easier to collaborate with the community and the maintainers.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jul 10, 2020

Firstly... Thank you for merging!!! I have been hoping for this to be merged for a long time.

I sent an email to the atom[at]github[dot]com earlier today, so I was thinking the same thing about joining Slack!

It seems like the fork is headed toward diverging and doing our own thing, but I think that will be less true if the cool stuff we want to do can happen upstream. Also, I am personally committing to upstreaming as much useful stuff as we do at our fork as would be useful upstream, and I have seen @aminya upstreaming a lot of stuff too. So we want to see upstream succeed, for sure and are going to spend some energy on that. (In fact we have not diverged far from upstream yet at all, so maybe we will stay pretty close, at least enough for it to be quite easy to send PRs.)

Thank you for the collaboration! It's been exciting, on a personal note, but overall I would like to see atom succeed, so that's why I'm here! Glad to help move things forward.

@aminya
Copy link
Contributor

aminya commented Jul 10, 2020

We will continue to make the pull requests from the contributions of atom-ide-community/atom. Once we have our releasing procedure tested, we will make a pull request for each version that we release in our fork (each release will only have one change/feature). Hopefully, the upstream team will have the same pace for merging the improvements, and this will keep the two repositories close to each other.

I was wondering if atom team can post atom-community builds on atom.io website. atom.io can treat those like nightly builds. If you accept to do that, it will be a huge boost in our passion and momentum, and we will double our care for keeping the two repositories in sync.

@DeeDeeG @lkashef

@lkashef
Copy link
Contributor

lkashef commented Jul 11, 2020

Firstly... Thank you for merging!!! I have been hoping for this to be merged for a long time.

Thank you for the contribution 馃檱鈥嶁檪锔 it's all about priority but this was definitely an important follow-up PR to the Python Dependency PR so thanks for the due diligence.

I sent an email to the atom[at]github[dot]com earlier today, so I was thinking the same thing about joining Slack!

Sounds great, looking forward to seeing you around, feel free to reach out if you had any problems with your invitation

It seems like the fork is headed toward diverging and doing our own thing, but I think that will be less true if the cool stuff we want to do can happen upstream. Also, I am personally committing to upstreaming as much useful stuff as we do at our fork as would be useful upstream, and I have seen @aminya upstreaming a lot of stuff too. So we want to see upstream succeed, for sure and are going to spend some energy on that. (In fact we have not diverged far from upstream yet at all, so maybe we will stay pretty close, at least enough for it to be quite easy to send PRs.)

I am sure you folks have your own vision and drive, I wouldn't expect to be 100% on the same page but the direction of working on stuff that would help the upstream direction is definitely appreciated.

I would also suggest (you are free to take or leave my suggestion) adding the stuff that improves the core upstream into the fork and what extra cool features you work on to their own packages, to maintain a flexible core that the community can build on top of.

Thank you for the collaboration! It's been exciting, on a personal note, but overall I would like to see atom succeed, so that's why I'm here! Glad to help move things forward.

I feel the same @DeeDeeG, I am personally excited to see what you can bring to Atom and would be happy to assist whenever possible to support your mission.

@lkashef
Copy link
Contributor

lkashef commented Jul 11, 2020

We will continue to make the pull requests from the contributions of atom-ide-community/atom. Once we have our releasing procedure tested, we will make a pull request for each version that we release in our fork (each release will only have one change/feature).

Sounds like a good plan!

Hopefully, the upstream team will have the same pace for merging the improvements, and this will keep the two repositories close to each other.

I think if the fork is stable enough and has PRs that improves the overall stability of Atom, it will encourage maintainers to merge more things to upstream with more confidence

I was wondering if atom team can post atom-community builds on atom.io website. atom.io can treat those like nightly builds. If you accept to do that, it will be a huge boost in our passion and momentum, and we will double our care for keeping the two repositories in sync.

I won't be able to directly help you with that but I can definitely bring it to my manager, however I would say it's best to wait until you have a stable momentum and proper build environment to best showcase your idea.

@DeeDeeG
Copy link
Contributor Author

DeeDeeG commented Jul 13, 2020

Hi @lkashef thank you for the invite. I don't think it made it to my inbox (I checked the Spam folder as well).

Could someone re-send the invite?

I mentioned in my email just now that I'd post some randomly generated strings here in this issue. They should match the ones in my email, which helps to prove the email is from the same person as me @DeeDeeG on GitHub.

Randomly generated strings (click to expand).
mLypSWB93I3hnAtuxqjf
KwcQBKfkz1HislQjScKK
SF0EIRunOZbPJP6zx71x
8CziK2ChbnLTcQvhofej
5xy1kD0iaHj9mJ7lcZxZ

Thank you!

- DeeDeeG

@DuyAnhComputer
Copy link

DuyAnhComputer commented Jul 19, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants