https://github.com/clepple/nut/pull/2#issuecomment-9356397
same comment from before still stands: [I took the liberty of replying on nut-upsdev - not many people are using github yet since the NUT repository native format is still SVN.] Also, "pull requests" don't really make much sense when we are still committing back to SVN, either. With git-svn, we can't do arbitrary merges - we can only rebase and run "git svn dcommit", which flattens out the repository history. Github assumes you are running a native Git repository, so closing a pull request doesn't make it clear whether or not the code has been merged. > Charles, > > I'm all for merging it into the trunk, as per our discussions on the > high-level APIs and bindings. > A quick review shows that the code is clean, and well isolated. I won't disagree with that. > Moreover, Emilien has created a new NUT client > (https://github.com/balooloo/hazelnut), that requires it. > This wxWidgets project is promising, and I intend to put my (light)weight > behind it, to solve the "ultimate NUT UI" issue. IMHO, an external NUT client is not a reason (in and of itself) to merge libnutclient into NUT. But I won't pursue that argument further. > @balooloo : I would however like to see some documentation. Strange that you > missed that! > The right place to insert this is 8.2 (after C/C++, before Python) In my mind, this is the biggest roadblock to merging. Developers need to know that this library exists (News section of website, etc.) and need to know why they might want this over the existing C API. Then, they need to know how to use it. Much of the benefit of a wrapper library evaporates if a developer has to basically read through the code to understand how to use it. At the very least, the code in hazelnut can be cited as an example of how to use libnutclient. -- Charles Lepple clepple@gmail _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
