I agree better merge after your refactoring to new approach.
Looking forward to see your new version.
Hi David and Ming,
> On Apr 25, 2015, at 10:51 PM, Super-User <address@hidden> wrote:
>
> May I suggest having this project hosted on Github also?
> The facilities on Github enables better managements of issues, goal, test cases, and of course, the codebase itself, especially code merges.
> In addition, programmers unaware of / non-subscribing this mail-list can also contribute by making pull requests, as in any open-sourced projects.
> To push it forward, I need consent of anyone else who have also contribute the code, and agree on the license GPL v3.
This is fine with me. At some point I think it would be a good idea to add this to openLilyLib, but I’m not sure if it makes sense to go ahead and do that now, or to work on it on github independently and then move it to openLilyLib later once it’s more mature.
https://github.com/openlilylib/openlilylib
Urs, what say you?
I think my preference would be to add it to openLilyLib directly rather than set up a separate repo and migrate it later.
Ming is correct, my latest version does not include David’s latest changes. I hadn’t seen them before working on my revisions and I haven’t taken the time to merge them since I think the changes in my “6b" file will be superseded/obsolete after I implement the new approach. In short, I don’t think the changes in my version “6b” are worth merging with David’s version “6”.
In other words, the new approach will bring so many changes it makes sense to wait until I finish it before doing any merging. (It might even make sense to hold off on further development or setting up of github too. On the other hand, I don’t want to discourage David from working on this. So maybe we just figure out the merging when the I have a new version worth merging… probably with Github’s help.)
Cheers,
-Paul
2015-04-25_122547.png
2015-04-25_122629.png