[Proposal] move the project to an open organization about wiringpi-node

[nekuz0r]

The organization idea and github page is great, i just created the organization, i will invite you.

About splitting it into smaller package, i am not quite sure it makes sense:

• To lib is not that big
• It will have to compile each micro package against wiringPi library at install (slower than compiling everything once)
• Most of the core library code will be duplicated in memory (static link)

I don't see a real benefits to splitting it up.

In the other hand, providing prebuilt binaries would be a great thing.

[eugeneware]

Hi Everyone. I've got some good news.

I've reached out to Phil Howard (@Gadgetoid), who is the owner of the official WiringPi GitHub Org about our interest to join the @WiringPi org.

He's very happy for us to push our repo to that organisation, as well as being open to give us rights to add / modify contributors as part of our open contribution policy!

So, if everyone is OK with this, we'll kick off the transfer?

Woo!

[nekuz0r]

I cannot give you write permission on this repository, maybe we should already duplicate this codebase to the wiring-pi organization and start working there.

You should have received an invitation.

[eugeneware]

Ok. The transfer is complete. I've pushed the repo to @WiringPi/WiringPi-Node

There's a few places in the source code that I think we need to update.

The first is the package.json and I also note that the install.sh file git clones from https://github.com/nekuz0r/wiringpi currently.

Ie. at https://github.com/WiringPi/WiringPi-Node/blob/master/install.sh#L43

@nekuz0r - what do you think we should do about this? Can this be changed to pull from this repo now?

[FlorianWendelborn]

@eugeneware Awesome. Glad to hear that you managed to move this to the real @WiringPi org.

[NoHomey]

👍 for the prebuilds there is only one target so it will make things easier than the trivial case of i386 and amd64. I would also like to receive a commit access so I can start an own branch where I can move the System Error proposal from #59 . I've just started a document describing how syscall's property value will be deducted based on errno value.

[NoHomey]

I would like to propose and orranization icon:

[NoHomey]

I want to ask @soarez and @eugeneware what they think about the proposal to move the project to the newly created wiring-pi organization. As well to discuss the idea of possibly moving the project to the official WiringPi organization. So pushing the project towards v3.0 milestone and making it more popular can happen.

[eugeneware]

I love the idea of moving it to an org. Happy to move it if everyone is in favor!

[soarez]

No objections from me, the baton has been passed to @eugeneware long ago and every time I peek again into this project I see that he's done a superb job of maintaining it. As I see it, he's the man in charge of this.

[eugeneware]

Awesome! To do the transfer to with @wiring-pi org, I need to have Admin rights to the Organisation apparently. @NoHomey if you could arrange the appropriate bits I'll do the transfer? I tried to push but it wouldn't let me.

[NoHomey]

Unfortunately I don't have admin rights either. @nekuz0r is your guy.

[eugeneware]

Hi @nekuz0r, if you can give me admin rights to the new Organisation I can push this repo over to it.

[nekuz0r]

@eugeneware Yes sure, doing it right now :)

[nekuz0r]

@eugeneware Great !

Yes package.json git url can be updated.

As for the wiringpi repository cloned in the install.sh my fork contains some additions (like cancelable ISR, tcs3725 support, dac7678 support, pulseIn, pca9685 support) that are not in the main wiringpi repository.

I tried once to reach at gordon for those changes to be included in the main repository, but i never received any answer.

[eugeneware]

@nekuz0r I've updated those files and change the URLs to its new home in the @WiringPi organisation. I've published the minor update to npm as 2.2.1.

I was also speaking @Gadgetoid, and it seems that Gordon may be taking a bit of a break from the project. So the official repo may end up living on Github eventually after all. I see that @Gadgetoid has been merging PRs to the Github repo, so it might be worth submitting a PR to it, and trying to land it there.

Phil also indicated that he's open to new contributors breathing life into any of the repos in the WiringPi organisation and helping to maintain it.

If that sounds like something you're interested in and if it's OK with @Gadgetoid we can get you access to @WiringPi/WiringPi too, and assuming the PR lands we can change the install.sh to point to there?

[nekuz0r]

@eugeneware This sounds perfect, i will make a PR to the WiringPi/WiringPi repository without all the changes a made in my own fork.

So once it's reviewed and merged we will be able to move back to the official repository.

[eugeneware]

@NoHomey - I've invited you to the @WiringPi org, so you can start the work on breaking wiring-pi into smaller modules.

I've also added @soarez and @nekuz0r as well. You'll need to accept the invites before we can give permissions to transfer/create no repos under the org.

[Gadgetoid]

Hi Folks!

First off, welcome aboard, or I suppose it's almost the other way around. I've been single-handedly maintaining the various ports of WiringPi found within the "official" org for the last 4 or so years now. It's great to have new people aboard and I'm generally happy to have a little more activity within the org.

I must say, the org is only "official" in the sense that Gordon hasn't told me off for putting it together, and because I've been working on these WiringPi ports for almost as long as WiringPi, and the Pi itself, has existed.

As for the WiringPi mirror, Gordon is still actively maintaining WiringPi albeit slowly and surely, and remains fairly opinionated about what makes the cut in the library. I think that's very much his prerogative but I understand that it doesn't quite mesh with how many of us believe an OSS project should be managed.

I'm currently discussing how we should move forward with Gordon, since I don't want to act against his wishes and create an "officially unofficial" fork.

[eugeneware]

Hi @nekuz0r - Sorry for the confusion. It looks like Gordon is still actively maintaining the fork, and it still makes sense to submit the PR to the original repo to get it merged in. In this light it's much better to all work together with Gordon rather than create possible confusion, or create any resentment with the author.

[NoHomey]

@eugeneware sorry for actic so slow. About split to micro packages @nekuz0r is right about duplicate memory that will come with spliting but I still thing that more users will benefit from it since most don't use whole funcionality at once. No matter what decision about spliting we make re-writing using Nan is required. I can do both or just help with the re-writing so wiring-pi can catchup faster with node's LTS and latest releases.

[Gadgetoid]

Hi @nekuz0r, I don't know where the best place to ask is, but I was wondering about the rename to ".cc", the restructuring and the additions to the underlying WiringPi library, and what the rational behind them was?

I've been discussing with Gordon how best to move forward with ports, and encouraging him to move to GitHub so that his thought processes behind WiringPi can be a little more transparent. This is still ongoing.

Obviously nothing precludes us from making our own changes to a fork of the upstream library, but I would suggest two things we keep in mind when doing so:

• All libraries should share the same fork of WiringPi and have feature parity
• It should be made abundantly clear in any documentation that bug reports/feature requests/questions etc be directed at us

I think you've done a better job than me at this so far anyway!

These suggestions are by no means rule of law, but I think it would be nice to have a concise set of libraries that behave the same way, have the same features and can hopefully benefit each other as a result. Ultimately I don't mind how the Node port is maintained and shaped, and much of the decisions and rationale may be beyond my immediate understanding since I've only dabbled in Node.

Finally, prebuilt binaries is something I'm interested in for the rest of the ports. We've had a major effort over the last few months to package all of our Python libraries here at Pimoroni, for distribution via the Raspberry Pi apt servers. It would seem sensible to do the same with the various WiringPi ports, although those that I maintain need some serious TLC before they're ready. However, and I'm not certain, but I suspect the "correct" way to approach this would be with ports that use the existing, binary shared libraries supplied by the wiringpi package. I may be wrong, but this is not congruent with the way any of our ports work currently.

Thanks for listening!