<br><div class="gmail_quote">2012/10/12 Emilien Kia <span dir="ltr"><<a href="mailto:kiae.dev@gmail.com" target="_blank">kiae.dev@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2012/10/12 Charles Lepple <<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>>:<br>
<div class="im">> <a href="https://github.com/clepple/nut/pull/2#issuecomment-9356397" target="_blank">https://github.com/clepple/nut/pull/2#issuecomment-9356397</a><br>
><br>
> same comment from before still stands:<br>
><br>
> [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.]<br></div></blockquote><div><br>you did well.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> 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.<br>

><br>
<br>
</div>Agree, but it helps to track code to merge.<br></blockquote><div><br>and to prepare the future transition to git, and a possible external use of github...<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">

>> @balooloo : I would however like to see some documentation. Strange that you missed that!<br>
>> The right place to insert this is 8.2 (after C/C++, before Python)<br>
><br>
> 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.<br>

><br>
<br>
</div>Agree too.<br>
I can write a little paragraph to talk about this lib (in C/C++ sub<br>
chapter)</blockquote><div><br>I'm really in favor of a dedicated chapter, Ie 1 for libupsclient and 1 for libnutclient:<br><br>8. Creating new client<br>8.1. C / C++, using libupsclient (low level API)<br>8.2. C / C++, using libnutclient (high level API)<br>
8.3. Python<br>...<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but I think writing man pages is not really efficient due to<br>
the API size (in term of function number). IMHO a doxygen like<br>
documentation is more relevant. I will work on that, but perhaps the<br>
merge can be done without this.<br></blockquote><div> <br>I agree with Charles that manpage doc is useful, and part of our (NUT) documentation approach (as for libupsclient).<br>Though my stance is that it's probably only suitable for C, not C++.<br>
<br>instead of created a manpage per function, you may create aliased manpages.<br>Ie 1 manpage for all the C interface, or 1 manpage per coherent block.<br><br>Doxygen is still a point to dig again, for the developer doc completion.<br>
and this will probably be more suitable for C++.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> At the very least, the code in hazelnut can be cited as an example of how to use libnutclient.<br>
><br>
<br>
</div>Why not, but this code will increase and, as it uses UI lib, it is not<br>
really easy to understand.<br>
I am working on a little C++ program using libnutclient which query<br>
upsd and dump results in csv file. This is probably a better example<br>
of what it can do and how to use it.<br></blockquote><div><br>2nded, for the same reasons.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> - a pkg-config support file<br>
<br>
That is commited.<br></blockquote></div><br>counter-checked. works for me.<br><br>Emilien: don't hesitate to tell me if you need some help on the Asciidoc chapter + manpage.<br><br>cheers,<br clear="all">Arnaud<br>-- <br>
Linux / Unix / Opensource Engineering Expert - Eaton - <a href="http://opensource.eaton.com" target="_blank">http://opensource.eaton.com</a><br>Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.fr" target="_blank">http://arnaud.quette.fr</a><br><br>