-
Notifications
You must be signed in to change notification settings - Fork 159
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
Co maintenance #9
Comments
I'm up for this, for noble at least. I use a Mac on Mojave but am used to working across all the platforms including mobile? |
cc @jrobeson, who also has a noble fork with a lot of updates/changes. |
In this case it wouldn't be abandonware at all then. If folks are interested in my refactorings, then it should probably get a new name and be redone as a monorepo. That's what I planned on doing. Feel free to take a look at my changes https://github.com/jrobeson/noble/commits/refactor |
Currently i'm attempting to refactor the hci-socket bindings to prepare for a merge of bleno code. |
Any mac developer interested to review: |
While I'm not a great low level mac developer, I have my own fork that combines noble-mac and @abandonware/noble for running across linux/mac, and it's been working ok for me so far. https://github.com/qdot/noble-mac/tree/abandonware-fork I've also had some luck with noble-uwp too on windows 10, though I mostly use straight C# there. |
@qdot would you like to co-maintain noble here and join @abandonware/maintainers to merge current open PR ? Before, please send a PR that add your name to a file "MAINTAINERS.md" and add a message that you comply to contribute for community interest and do not plan do malicious things, the commit should be verified too, I can provide an example if unclear. Regards |
@qdot does that mean it works across other platforms too? |
So what's the end goal of this comaintainership? Just to keep things working, or make significant changes? |
First merge fixes still under review upstream... and avoid to break API until upstream is open to new developments. So if you have experimental features, they could be based on @abandonware master or eventually in a "experimental" branch (eg: "sandbox/$user/master" ) |
I'm a bit beyond that at this point, so I guess i shouldn't apply for now. I already broke the API by requiring |
The API needs an update/rewrite, for sure. There's lots of undocumented stuff too. |
one solution would be to add in, a transition module that will add new unstable APIs like:
|
@rzr Unfortunately I'm not sure I'm best for maintainership on this for the moment. I deal with way too many projects as is right now, and while noble is an important component in of some of them, it's not really something I can split more time onto. I've just been sharing what I've done lately to get my system working. @marksyzm Inasmuch as any noble will "Work across other platforms". My fork just has a dynamic load path that checks for platforms at runtime. If it's darwin, it chooses noble-mac. If it's not, it chooses @abandonware/noble. Could be at some point I'll add another path to choose noble-uwp on win10. That's all it does, tho, nothing all that special. |
I am drafting a constitution for @abandonware/maintainers @abandonware/owners Any suggestions are welcome: |
There is only one maintainer (myself), who want to be next ? Please follow instructions at: Also feedback from @sandeepmistry is welcome @qdot I released a version, can you rebase your branch on @abandonware/maintainers 's master and Open PR on relevant changes: https://github.com/qdot/noble-mac/tree/abandonware-fork Relate-to: https://social.samsunginter.net/@rzr/101930569288659296 |
Based on @atrovato contributions may I propose him to join this list: |
As I said, elsewhere as creator of @abandonware org, I am open to co maintainership,
but it's hard to trust everyone, specially when taking over orphan packages. So I don't want to put users under any risk.
In short term, I propose this rule:
Any developer can apply but he should already has committed to an opensource organisation that he will behave nicely (to not intentionally commit malicious code), An explicit proof of commitment should be provided too.
Related links:
I am open to suggestions.
Tracking changes is also welcome, ask me how if unsure:
The text was updated successfully, but these errors were encountered: