consider octalbonescript instead of bonescript

[boneskull]

My fork uses octalbonescript, which is a drop-in replacement for bonescript.

It features the same API, except:

1. It's actually under development and maintained
2. Bug fixes
3. Performance improvements
4. Maybe even a couple features

Please let me know if you are interested in this.

[julianduque]

@boneskull why not join forces with @jadonk and mantain one single fork of bonescript, I tried octal before but has a lot of issues trying to implement it

[boneskull]

Dunno. You'd have to ask the octalbonescript folks why they haven't sent PRs or why PRs haven't been merged...

cc @theoctal

On Jan 21, 2015, at 14:56, Julian Duque [email protected] wrote:

@boneskull why not join forces with @jadonk and mantain one single fork of bonescript, I tried octal before but has a lot of issues trying to implement it

—
Reply to this email directly or view it on GitHub.

[jadonk]

They sent a PR in the past, but they changed the structure so much I
couldn't easily review it.

On Wed, Jan 21, 2015 at 11:39 PM, Christopher Hiller <
[email protected]> wrote:

Dunno. You'd have to ask the octalbonescript folks why they haven't sent
PRs or why PRs haven't been merged...

cc @theoctal

On Jan 21, 2015, at 14:56, Julian Duque [email protected]
wrote:

@boneskull why not join forces with @jadonk and mantain one single fork
of bonescript, I tried octal before but has a lot of issues trying to
implement it

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#17 (comment)
.

[adityapatadia]

Hello,
We forked bonescript for a simple reason. It was just not stable enough to be used in our near real time systems. Since I have a lot of Javascript experience, I forked and improved it over past one year.

As far as PRs are concerned, we sent them with better and industry standard coding style changes apart from functional improvements. They were not merged and since the delay was unacceptable for us, we just pushed forked version on npmjs to ease our internal deployment.

We are faced with 2 options here. First one is suggested by @boneskull which is to merge octalbonescript back to bonescript. The code is changed so much in last 1 year that I really feel whether it will be possible. One more concern is also about acceptance by @jadonk and adding me as maintainer. If fast-track development is not ensured, we are not happy to merge it back.

Second option is that whatever issues are faced by users, report them on octalbonescript github issues. I assure you to resolve them in short time span. As was the case with this package, other packages may slowly migrate to octalbonescript. May be in future, BBB community can accept octalbonescript as better and official alternative to bonescript.

I would like to point out that the changes made in octalbonescript are just to make it more usable and stable and no functionality was affected as a result. The current usage testifies the same. We follow fast track development cycle so some users might have faced some bugs but we always try to resolve them fast. We have plans to make octalbonescript even more stable and more user friendly. The community can expect a lot of bug fixes and improvements in upcoming 2 months. We are trying to move quickly towards v1.0.

Looking forward to your support. :)

Cheers!!

[boneskull]

@adityapatadia

My hope is that you can work out some sort of arrangement with @jadonk.

As far as PRs are concerned, we sent them with better and industry standard coding style changes apart from functional improvements. They were not merged and since the delay was unacceptable for us, we just pushed forked version on npmjs to ease our internal deployment.

I'm going to have to question this statement. I see two (2) PR's from you in bonescript. One was merged; the other was not. @jadonk asked you to separate the style changes from functional ones, which you claimed was too difficult.

It's unclear why jadonk/bonescript#83 was closed by @jadonk, but there was no protest on your end. You claimed you would send more PRs but never did so. Perhaps you wish to merge into bonescript with impunity, and if @jadonk wants changes, forget about it.

You can use your fork and send PRs back to the main project; this is what good open-source citizens do. It's poor open-source etiquette to fork a repo, send a PR, then if it's not merged verbatim, take your toys, go home, and publish a web site claiming, "The most reliable JS library for your BeagleBone. One that just works!"

jadonk/bonescript#83 sat for five (5) days before getting attention; it's unreasonable to always expect an immediate response. Publishing to npm was not necessary; it's trivial to npm install --save https://github.com/theoctal/octalbonescript.git.

This all points to an unwillingness to work with @jadonk. Regardless of whether your fork has "industry-standard" coding practices, bug fixes, better performance, etc., you should work together to get your changes back into the official library, period.

Perhaps your company's requirements and the BB community's needs are at odds, which could explain this behavior. Perhaps it's a way to capitalize on the work of others and gain attention for your business. So, please understand, I'm not necessarily blaming you personally; I'm just calling it as I see it.

[boneskull]

This discussion may want to migrate to theoctal/octalbonescript#14.

[julianduque]

I will consider this but would like to have a basic gpio implementation without all the overhead added in bonescript and octalbonescript