inactivity revisited + too much forks about cwiid

[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.

[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]

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/