-
Notifications
You must be signed in to change notification settings - Fork 491
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
Adding libesphttpd #456
Comments
It seems suitable for the extras and an example would help too. Many of the extras reference external repos, and if you plan to maintain and support it then you could do that. If the changes are specific to esp-open-rtos then some conditional code seems fine, otherwise I think it helps the communities to make an effort to get changes landed upstream. I suggest keeping a repo that tracks the upstream, with a branch for the esp-open-rtos changes, and then try to whittle down the changes in time. This will also make it a lot easier to update the code to track upstream changes. |
Another wip: Spritetm/libesphttpd#38 |
I have no problems maintaining my own fork just because I don't have a way to make a full 100% test to make sure the upstream works with other projects it may be linked to. Maybe in the future, I'll make the things into upstream so the fork will not longer be needed. |
I created the initial pull request: #458 |
Hey folks.
I'm so in love with esp-open-rtos and libesphttpd, so I think these two must live together.
For that purpose I recently modified libesphttpd to work with esp-open-rtos (as one of the "extras").
Things currently work:
"Bonus" features:
I think it should be fair for me to share my work of porting the libesphttpd.
It's currently implemented as a fork of libesphttpd. Is it acceptable way to contribute or it should be integrated into the original project first?
I'm kinda new for this stuff. Please let me know what do you think.
The text was updated successfully, but these errors were encountered: