inactivity revisited + too much forks

[alien999999999]

Hi,

I'm a distribution packager for Mageia ( http://www.mageia.org/ ) and i'm packager of cwiid.

The current released code is 3y old; while it seems there are still quite some development going on.

Since abstrakraft said himself that he didn't have much time for this, and he's not merging from any forks, i was looking on which fork that i can use as a release point.

However, there's too much forks, i cannot make head nor tails of which one i should have.

I would ask that any of you to continue and make a release and try to combine the existing forks back into one main thread. or perhaps have a fork/project where more than one developer can work on?

additionally, i would like for wminput -d to be forked into the background and sighup to reload. additionally, i can provide a systemd cwiid.service script for wminput -d.
another useful point would be to be able to hook up multiple wiimotes into extra uinput devices.

Perhaps if all of us have not that much time, perhaps if we work together, this would be resulting in a better project.

I would ask if anyone has a bit of time they can spare on this to answer here?

thanks in advance.

[alien999999999]

bump

[alien999999999]

oops, wrong button

[voidus]

Maybe @vitalogy could get in here, it looks like he/she owns the repository that is best maintained.

[abstrakraft]

I'd definitely be interested in discussions to hand this off (in whatever
"official" capacity the community desires) to someone with the time to
properly maintain it. I've also got some incomplete patches for Windows
and Mac compatibility that I could hand off.

On Sun, Oct 20, 2013 at 4:37 PM, Simon Kohlmeyer
[email protected]:

Maybe @vitalogy https://github.com/vitalogy could get in here, it looks
like he/she owns the repository that is best maintained.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-26686006
.

[alien999999999]

my primary interest is as a distribution maintainer (and user) and i'd like for most forks it's patches to be merged in an official well maintained fork, that i can use as a stable source.

[knarrff]

I came here, like others, because of a small potential contribution. Now the best strategy for me, without taking over the whole project, seems to be yet another fork, with minor changes, and not a lot of hope to get them pulled. I am not sure if this would really help the project. On the other hand I can understand abstrakraft.

[umlaeute]

👍 as i'm in a similar situation as @alien999999999 (i'm Debian maintainer and although i'm not the maintainer of cwiid in Debian itself, i have packages that depend on it)

while there are many forks, many of them have been merged back into various branches.

i tried to quickly evaluate the network in order to condense it, and came up with the following set of branches.
i did not do any functional tests, but mainly tried to eliminate all branches that had already been git merged into some other branches, and then check of the leftovers, whether there had been any off-the-tracks merges (e.g. manual copies of code snippets):

mzimmerman/master

this seems to be the most active development and has merged in
many* other forks (including @vitalogy).

pekkav/master

@pekkav has a larger master branch, that was forked off abstrakraft/master a while ago (somewhen in 2009, that is: before current abstrakraft/master/HEAD).
the branch might also be of relevance, as it seems to be the one that current Debian and Ubuntu packages are based on.

folg/master

the only changes not yet found in mzimmerman/master are

• support for EXT_GUITAR (simply recognizing the ID and treating it as classic)
• return non-zero if cwiid_close() fails

rektide/master

tries adding support for RVL-CNT-01-TR

application-forks

the following branches tweak the applications (wmgui, wminput)

ers81239/master

some changes to wmgui, mainly about logging.

esaule/master

single commit with a fix for wminput to allow for re-loading of the configuration during runtime

maggu2810/master

single commit that adds a cmdline arg to wminput to specify name for uinput device

tSed/sma/cross-build-compliant

making wminput and wmgui optional (i think this is partially obsolete by the --disable-gtk flag in mzimmermann/master).
however, it also disables building wminput for python3 (as they are incompatible)

others

robots/master has some (disabled) code for parsing passthrough data from both nunchuck and classic, but afaics all active changes already made it somehow into mzimmermann/master)

rhlee/wait has some totally undocumented code changes that seem related to some udev support in wminput

deejaydarvin/matlab_and_puredata seems to simply include 3rd party code (puredata and matlab extensions that use libcwiid; i don't know about matlab, but at least for puredata the code imported here is quite old and there are better maintained alternatives these days, so i would just drop that)

mzimmerman/nostatus (haven't done a close examination)

the remaining forks/branches could simply be eliminated, because they had already been merged into at least one of the above.

conclusion

it seems that @mzimmerman has the most up-to-date version of libcwiid.
including some of the minor other forks (rektide, folg for libcwiid, ) should be trivial. including some of the application-forks (ers81239, esaule, maggu2810) might be simple.
including pekkav/master ought to be evaluated.
the other branches might be ignored.

[umlaeute]

ah, and maybe we should just create a "cwiid" organisation, where multiple people have write-access to.

[alien999999999]

i was gonna ask if someone can contact this @mzimmerman and have pull-requests into his tree...
cwiid org doesn't sound bad, but someone has to maintain all this, since mzimmerman is most active tree, perhaps he'd be open to be maintaining it? and possibly do a stable release at some point? so i can base cwiid package on that?

[mzimmerman]

I'm an active github user, but I don't think I'm the guy you want. I pulled in a lot of other code because I wanted all the bugs fixed that were identified. I followed the github tree and pulled in code that looked like it was doing that.

My primary goal with cwiid though was to use it in a Go program called mythgowii which is like mythpywii but written in Go. mythpywii kept flaking out on me some and I've been working in Go lately.

Why I forked cwiid is because of this issue in mythgowii where calling disconnect would call a deadlock in the C code as called from Go. Primarily it was this commit that fixed the issue for me.

Anyway, I'm not a C coder I guess is what I'm saying and I only have a moderate interest in cwiid (I scratched my itch). I'll gladly allow others permission to commit and merge pull requests to my fork though if that's what everyone wants to do.

[abstrakraft]

As mentioned earlier, I'd like to assist and advise with any effort to clean up and centralize CWiid, but I don't have the time to do it myself.

With respect to the core library (libcwiid), I'm not sure if there's any value putting a lot of time into it - rewriting it as a wrapper around the wiimote kernel API is the way to go.

[alien999999999]

if we have a sort of group like umaeute said, perhaps we can just merge everything and let the all the individual users commit (ie: all those who committed and forked)

maybe then, we don't need to do any managing :-)

@abstrakraft what's this about wiimote kernel API? i'm not sure i follow... are you saying there's a kernel module that does similar things like libcwiid? ie: a simpler way to just connect bluetooth and use it as a pointer in X? or am i misunderstanding you?

[abstrakraft]

Yes, see https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/hid/hid-wiimote.h.

I think there's still value in the libcwiid API as a convenient way to deliver messages (although there may be another standard way to do this, if so, let's do that) to applications that want to use a wiimote as something other than a pointing device (for that, see XWiimote). You can find a number of posts blasting CWiid and other early libraries for implementing what are essentially userspace drivers, which is an accurate criticism (although unfair, considering the lack of support for kernel-space drivers for bluetooth devices in 2007).

[knarrff]

I agree that using the kernel driver is probably the best way forward, but I also agree that the kernel driver does not (and should not IMHO) deliver some nice features a user might want and a user-space library could provide.

I also think that using a group to collectively develop would be best. We have to keep in mind that it is not only us such a solution would serve, but package maintainers as well that are of course discouraged by a fork and merge mess like we currently have. Having said that however, I cannot commit to do this management myself, even if it is potentially not very much work after all.

[alien999999999]

see http://dvdhrm.wordpress.com/xwiimote/