Syncing strategy

[Sebastian Spaeth]

On Fri, 10 Dec 2010 19:43:02 +0100, Nicolas Sebrecht wrote:
> 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.

No one expects you to follow all other people feature branches.
 
> 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.

Calm down :). All I have been doing is experimenting in a single file, I
didn't even commit so far. So speaking of a topic branch is a bit
exaggerated. This is more (or rather less) than WIP, it is still just
experimenting with stuff.

Could I have sent the patch by mail? Yes, but half an hour later, you
would have had 3 more mails with different versions that looked quite
different.

All I did was sending a http link to a rapidly changing file.

I do see that you want us to inform and educate about the offlineimap
workflows, and I appreciate that. But looking at the mail archive of the
last month, you should also recognize that I am not shy to send lots of
patches via mail. :-). And their version 2... and 3... :)

(BTW, I appreciate your thorough reviews of those, it helps eg to detect
changes that have crept in).

> It is written in the Git documentation: release soon, release often. 

My writing of OSS predates git :-): I have been contributing since 2000,
and I value that policy very high. It is also the reason why I sent
patches in dozens to the list. 

But release early, release often doesn't mean to me that I should send
patches of files that change their content every half hour anyway. This
is less than Work in Progress, this is still embryonic state. I haven't
brought things up to a point where they can actually do something really
useful, I am still laying foundations. And noone wants to watch my
versions of that, believe me :)

> 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.

We are talking 250 lines of python, which are still undocumented and
therefore hard to grasp. This needs more than refactoring. This still
needs to be written.

I was actually waiting for some of the stuff in next to move into master
before I start sending patches again. I want to minimize everyones pain
in writing patches against master when I really aim them to be on top of
next :-).

> 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.

Sure, will send the patch as a reply to this mail. It is a single patch
so far, so it will certainly need breaking up etc.
 
> /tmp is certainly not the good path. We must have a dedicated temporary
> directory inside the test path.

Why is /tmp not a good temporary directory? I am using pythons mktmpdir
function to create it, run the tests and clean it up after the tests
finish. What's wrong with using that?

> > The test succeeds if it ends up with the same message in
> > both Maildirs afterwards. 
> What is the definition of "same"?

So far, and that could easily change, it means they have the correct
number of mails in the dir and they have the same UIDs:
localfolder.getmessageuidlist() == remotefolder.getmessageuidlist()

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

Same as above.

> > 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?

Right, we could. It would just defeat the purpose of testing syncing
:-). I currently run syncing tests that are offline, ie no IMAP server
involved. For that I do Maildir<->Maildir syncing.

> Could you please talk in patches?

See reply to this mail.

Sebastian