Communication during Nemiver SoC 2011

[Dodji Seketeli <dodji seketeli org>]

Hello,

I thought I would write a little note about how I think we could
organize communication throughout this Summer of Code.

First of all, congratulations to Seemanta Dutta and Fabien Parent for
being accepted into the Google Summer of Code program.  I am excited
by the idea of hacking with you guys :-)

* General communications

I think we could just use this mailing list extensively.  I believe it
is low traffic enough to enable people to stay focus and just ignore
messages they don't care about.  So I really encourage you guys to ask
every single question you could have, to the list.  Really.  In my
opinion, as far as hacking is concerned, there is no dumb question.
The good things with this list is that I am not alone to be able to
answer questions.  It is also archived and probably indexed by your
favorite search engine.  So please use it.

You can also reach me on IRC in channels #c++ and #gnome-hackers on
the irc.gnome.org server.

* Getting in the code and documentation

Both of you already have a feeling of the code base so I what I am
going to say here is probably going to be redundant for you guys, so
let's say I am writing this to have it archived and indexed.

First of all, if you are going to hack on a GNOME2 based environment,
your work should be based on the gtk2-branch.  Otherwise, if you are
in a GNOME3 environment, your work should be based on master.  I
maintain both branches actively.

** Configuring for hacking

A proper way to hack on Nemiver is to first define this environment
variable:

    NEMIVER_DEVEL=on

This will trigger compiling Nemiver without optimisation, with debug
info and will also enable the compilation of the regression tests.

I use the bash shell, so I have just set this in my ~/.bashrc to have
it permanently:

    export NEMIVER_DEVEL=on

To run the regression tests and be able to extract the API doc, you
also need to have the boost-test and doxygen packages installed.

Then the build.  I usually build Nemiver in a directory separated from
the sources.  For instance, if Nemiver sources are in a directory
called 'topmost',  I create a topmost/build directory.  Then I do:

    cd topmost/build
    ../autogen.sh
    make #(okay, really make -j4 as I use a quad core)
    sudo make install
    make check

** Navigating in the source code

To navigate throughout the source code, which mostly means to be able
to jump to the definition a given symbol (and possibly jump back), I
use etags [yes, I use Emacs; what else?].  As any properly setup
autotools-supported project, the topmost makefile of Nemiver has a
'tags' target.  Make sure you have etags (if you use emacs) or ctags
(if you use vim) installed.  Then you just have to cd into
topmost/build and run:

    make tags

That builds the relevant TAGS files in the relevant directories, e.g,
topmost/build/src/TAGS.  If you use Emacs, load the TAGS file by doing
M-x visit-tags-table, and give it the path to topmost/build/src/TAGS.
There are similar incantations for vim users.  From there on, you are
welcome in the wonderful world of etags/ctags where you can navigate
seamlessly throughout the source code by jump from a symbol invocation
to its definition.  If use neither Emacs nor Vim, think twice.  It's
never too late to join the great Emacs adventure ;-)

** Building the API documentation

There is a little bit of API documentation based on the doxygen tool.
It also comprises an introduction to the object system used in
Nemiver.  You can build that documentation by cd-ing into
"topmost/build" and by issuing:

    make doc

That creates a topmost/build/docs/reference/html/index.html file that
is the documentation in question.

* Branches organisation and code sharing

I am thinking about creating a branch for each of you.  I assume you
don't have commit access to the GNOME Git yet, but that is not a
problem with Git.  You can host your tree where you want, starting
from your own local disk.  Then you can just send the patches (learn
to use git format-patch and git send-email) to the mailing list.  I
(or Jonner) will review them and apply them to the relevant branch as
usual.

Above all, I think my gold advice would really be for you guys to use
the mailing list.  Do not hesitate to ask questions, post observations
etc.  In my experience most people don't like email (and sometimes
rightly so) but it's amazing to see what hackers have achieved by
using this tool.

Happy Hacking!

-- 
		Dodji