= Wed June 26th 2013, 14h00 UTC+2 =

 * '''partecipants:''' iulians, ggherdov, idank, marmoute (maybe)

== meeting agenda (proposal) ==

Random items from ggherdov, in no particular order

 * where are we w/ the header files (i.e. [[https://bitbucket.org/istana/c-hglib/issue/6/write-header-file-w-declarations-for-level|issue 6]]) ?
 * outline your main datastructures. What are the objects you need to represent in C (eg, the client).
 * is a connection kept forever opened for all the run of the program using c-hglib? smth like {{{hg_init()}}} and {{{hg_close()}}}
 * communitation btween C and {{{hg serve --cmdline}}}. It is via FIFO (unix pipe) and not socket, do we agree?
 * question to idank: what other MODE where planned if any?
 * supposed to work on windows?
 * list of python hglib functionalities (extended tutorial ?) I mean: list of commands implemented by {{{python-hglib}}}? I guess c-hglib gotta do the same.
 * testing strategy: pyhglib uses nose, https://nose.readthedocs.org/en/latest/ . What about test first (see [[https://bitbucket.org/istana/c-hglib/issue/8/write-tests-first-its-a-trick-to-sketch|issue 8]])
 * can I "attack" a "living" server as I would do with one that offer a socket as IPC? I mean can different programs talk to the same commandserver ?
 * looks like {{{python-hglib}}} open a subprocess for each command,
   * http://selenic.com/repo/python-hglib/file/e738d6fe5f3f/hglib/__init__.py#l33
   * http://selenic.com/repo/python-hglib/file/e738d6fe5f3f/hglib/util.py#l168

= Wed July 24th 2013, 12h00 UTC+2 =

== ggherdov agenda ==

 * Not totally satisfied by commit https://bitbucket.org/istana/c-hglib/commits/75e05ec67e21f7814fa4136c97f89ed1b88cd9fa (topic: make the `hg_rawread` usage as close as possible to Matt's snippet).
   * I was expecting a more aggressive rewrite of '''all''' calls to `hg_rawread`. I detail some more here: http://mercurial.selenic.com/wiki/C-Hglib/hg_rawreadUsageParadigm
 * Midterm evaluation is this week. We're in the need of getting Matt approval on the level 0 header.
   * attitude
     * '''Only patchbombed code matters:''' do not expect people to go and clone your bbucket repo. If you want code to be reviewed, the only way is to patchbomb it to m-dev
     * '''No code flood:''' The less code you submit for review, the faster it will be reviewed. I would submit only the header and (possiblym but not sure) `main.c`. Not the implementation. To be discussed, anyway.
     * '''Up to now, you experimented:''' Please keep in mind that all implementation code you wrote was a '''personal experiment''', with the sole purpose of clarifying your mind on the problem domain. Please do not respond to questions in the list with "yes I see your point but in my implementation (elsewhere) I already fixed this and that". As far as m-dev is concerned, your bbucket repo does not exists.
     * '''People do not like to repeat themselves:''' make 100% sure that you address '''all''' issues pinpointed in the past. Here a list of relevant mail thread and IRC backlogs:
       * http://mercurial.markmail.org/thread/qsfwzmxzzs4ekuuv
       * http://mercurial.markmail.org/thread/f5irmijzatlephtw
       * http://markmail.org/message/ism45s5vp7jsbp5u
       * http://markmail.org/message/mrh66tuh6phivxml
       * http://bpaste.net/show/FW3tCYalMJIjNkgRwyOG/
       * and whatever else I forgot.