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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use dependency of itchat instead of a source hard fork #19

Open
huan opened this issue Sep 30, 2021 · 2 comments
Open

Use dependency of itchat instead of a source hard fork #19

huan opened this issue Sep 30, 2021 · 2 comments

Comments

@huan
Copy link
Member

huan commented Sep 30, 2021

If there are any improvements, we should feedback to the upper stream to keep the community and ecosystem as healthy as they can.

My suggestion would be that we should switch to use the dependency of itchat before we release this project officially.

Related discussion:

@lyleshaw
Copy link
Member

Compared to independent itchat, I prefer to refactor a web/UOS protocol code directly, although the last one may take more times, refactoring is a better options due to the age of the itchat code and some problems.

How do you think about it? @huan

@huan
Copy link
Member Author

huan commented Sep 30, 2021

My suggestion would be:

  1. The best practice is adding dependence to itchat and send back Pull Requests to it for improvements.
  2. A fork of ItChat is acceptable because that would be easy to be sync with the upstream repo
  3. "refactor a web/UOS protocol code directly" is acceptable, but I do not think it's the best practice for our current name wechaty-puppet-itchat. If we decide to do that, I'd like to suggest renaming our module to another name that does not include the itchat because we are not depending on it. (for example, rename our module to wechaty-puppet-uos)
  4. If we select the above option 3, then we should credit the ItChat in the copy/pasted source code.

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

No branches or pull requests

2 participants