more on maildir modification times!

[Abdó Roig-Maranges]

> My bad, I forgot about that. Well to make it clear, it's wrong to update
> the modification times of the files for the purpose of fixing maxage.
>
> In fact, I wonder if I should revert the whole patch (25513e90387f60).
>
> It applies to the initial logic of maxage[1] but the min(UIDs) new logic
> of the current WIP (PATCH v4) should make this fix unnecessary.

I agree, the min(UIDs) thing is much nicer!


> One thing you could do NOW for sure is to document how we use the
> modification times on files and the time sequence in the filenames.
>
> This should prevent from further mistakes and avoid you to worry too
> much about things like that in the future. You might want to check the
> comments in the code, what could be done in the API documentation and
> most importantly introduce a new "_doc/ImplementationDesigns.md" page
> for the website.

Ok, I'll do that. Don't wait for me to make a stable release though... 


> FMPOV, it would be _very valuable_ to introduce a documentation
> dedicated on the logics we use. We could later add the whole UID sync
> logic, threading design, etc, etc. Not going to say more about how much
> I think we lack such documentation but the fresh new website should make
> it very pleasant to do. ,-)

I agree more documentation on the internals would be useful.

Not sure about the website though (which is very nice BTW). In my experience,
documentation about the internals is most useful when found next to the code you
are modifying, in docstrings or comments.

Anyway, when I get some time I'll try to contribute with some documentation.


> Glad you chacked the last release candidate. May I ping you so you can
> test the revisited maxage logic once merged, before I tag it stable?

Yes, of course! I run from offlineimap master anyways, but some weeks may pass
until I update.


Abdó Roig.