Syncing strategy

[Nicolas Sebrecht]

On Thu, Dec 09, 2010 at 07:54:13PM +0100, Sebastian Spaeth wrote:
> 
> Well, I cannot let this one go without response...
> 
> "test suite" is quite a mouth full so far :-). 
> 
> my offlineimap fork on github (git at github.com:spaetz/offlineimap.git)
> has a feature/testsuite branch that contains it. 
> 
> Or download via http, it is essentially a single file test.py in a
> top-level tests directory:
> 
> https://github.com/spaetz/offlineimap/tree/feature%2Ftestsuite/tests

I know developers have public forks of offlineimap. I just _can't_
follow the forks and all feature branches they may have. No one
maintainer can do that for practical reasons.

But it is more the concept of "how to work together" that we can
improve. I do and will still encourage to send topics by mail here. Not
because of one of my pointless habit but because there are very good
reasons to do so.  Github help to publish topics in a manner but clearly
can't prevent from sending topics by emails. Here is why.

By using mail, developers who keep working on a topic branch enhance the
chances to have contributions from others. It is far less hard to read
and review an incoming mail than fetch/merge/log or whatever from some
forks and random branches states. Yes, I say _random_ states. People
don't know and won't look further to check if a public feature branch
was changed, since when and why. Emails help tracking releases on
topics. Contributors know what was said, when and why because everybody
have the information in their mailbox without any chances it has been
rebased or reworked in an odd/isolated manner.

By saying "you can look at 'my-public-repository' in branch 'br'" you're
asking to people to go to their local repository, add a remote, fetch
one (some) temporary branch, checkout that branch, try to see history
against an official release or branch (finding which one is the better).
Do you think this will be done for every developer asking to do so and
for each new feature branch? Do you think it will be done for you? No,
it won't be. And I don't do it myself. So, let's do the work for them
and send the information (topics) you want to share by yourself.

What I see when someone don't share his topics by mail is that he
finally works alone and works with long-living branches off of the
project. This is strongly discouraging. More importantly, this is not
valuable for the code itself. Long-living feature branches should be
avoided as much as possible to stick as near as possible to the
released, deployed, tested and used code.

It is written in the Git documentation: release soon, release often. The
idea behind that is "don't fork too far from the mainline". Do the work
step by step. Need some refactoring? Implement it and get it merged
upstream first.  It will be tested by others while you're working on
something else.

Have a new experimental storage format in SQL? Mark it as experimental
and get it merged upstream.

Have a test suites started? Get it merged upstream. People will have fun
running the 2 or 3 first tests trying to find the failure somewhere.

> The code is still undocumented as absolute work in progress and things
> are being shuffled around still.

Please, send the first topic. Say it's WIP and ask people reviewing the
code they read. To help them to test topics, I try to publish
interesting topics on my public repository. They won't have to do much
work to test topics they have interest enough.

> which is responsible for creating a fake configure object, setting up 2
> maildirs in a /tmp dir,

/tmp is certainly not the good path. We must have a dedicated temporary
directory inside the test path.

>                         providing a "putmail" function for creating new
> mails and deleteing everything after the tests are done.
> 
> Then the class TestOfflineImapFunctions(unittest.TestCase):
> 
> contains the actual test cases. Currently there are 2 test cases.
> 
> 1) Sets up two maildirs, copies a message into one and syncs in the same way that offlineimap
> usually syncs. The test succeeds if it ends up with the same message in
> both Maildirs afterwards.

What is the definition of "same"?

> 2) it resyncs without having changed anything, and checks that nothing
> has changed afterwards.

Ditto.

> So far so good.. The dificulties:
>  - Offlineimap does not support Maildir2Maildir syncing using the
>    high-level functionality. I understand this is due to the
>    impossibility of doing IMAP<->Maildir1<->Maildir2<->IMAP2 (because of
>    different UIDs being assigned to the messages by the servers). But
>    for testing purposes that hurts me. And I will propose patches to
>    make that easier. But that is not urgent.

I'm not sure I understand. Why would we want syncing Maildir to Maildir?
We can 'cp -a' the maildirs for the tests, no?

Could you please talk in patches?

-- 
Nicolas Sebrecht