Re: tinymail mono bindings

["Bart Deleye" <bart deleye gmail com>]

Just let me know which channel and I'll be there!

On 9/27/06, Philip Van Hoof <spam pvanhoof be> wrote:

On Wed, 2006-09-27 at 12:21 +0200, Thomas Van Machelen wrote:

> Maybe we should gather in an irc channel on gimpnet or freenode.  What
> timezone are you guys in.  Philip and I are in CET.

Bart is also a Belgian CETter, Yoan I don't know. Bjorn, who's also
interested in .NET bindings, is also a Belgian CETter. Bart and Bjorn
know each other (friends).

It indeed looks like the .NET bindings are going to be a Belgian thingy
mixed with Yoans contributions :-). But please do talk English with each
other. For the following reason: if Yoan asks for meeting logs, you guys
don't have to translate it. Same for mailing lists discussions. Let's
stick to English.

Where you guys meet, I don't care a lot about that. Feel free to start a
channel called #tinymail or create a jabber chatroom. I propose to use
free communication channels. So that every body can join.

So ... Please indeed get your heads together and cooperate rather than
wild-wild-west coding it. Once you guys have something that makes sense
(that could actually be committed and wouldn't break existing things),
so that I can see that you guys are serious, I will allow one of you
guys to create a branch copy of trunk and patch that branch with the
work.

If needed, I can create this branch and do the initial import too.

Each one of you guys is hereby allowed to ask for SVN write access, and
will get it from me. But please do post patches to the mailing list
before committing things in trunk. For example when you are planning to
sync the branch with trunk, I would love to get informed first.

In the branch, you guys (as a team on itself) are more or less allowed
to do whatever you want. Except on purpose fucking it up ;-)

I might also join up and create some patches for the .net work sooner or
later. It does, however, depend a-little-bit-a-lot on my time and todo
schedule.

When committing on trunk, follow the guidelines as explained on the
wiki. For example API changes must be marked in the ChangeLog. Changes
must have a record in the ChangeLog. AUTHORS files must be updated.
Documentation must ALWAYS be correct when API changes happen (they
happen in THE SAME commit or a commit that comes rapidly after it, not a
commit that takes days. Because that means that you should have delayed
the first commit and finish the work plus documentation first).

New features and types typically get new unit tests. But I can imagine
unit tests for language bindings aren't going to be easy. But please try
to think about some sort of testing for the language binding. Preferable
one that can be (partly) reused by the Python language binding too.

Etcetera etcetera (I'm not a difficult guy, I just want things to stay
nice, documented and testable AND tested and frequently REtested and
REtestable).


--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be