Patches updated to nicolas/pu

[Sebastian Spaeth]

On Tue, 30 Nov 2010 20:10:32 +0100, Nicolas Sebrecht wrote:
> On Mon, Nov 29, 2010 at 04:05:51PM +0100, Sebastian Spaeth wrote:
> > 
> > I have continued to clean up the code base and propose the total of 27
> > patches (many of them minor) for inclusion. I have rebased my patches
> > against current Nicolas/pu for ease of pulling.
> 
> Do you really have to? 'pu' stands for 'proposed updates'. Topics here
> won't be merge to the next release unless more work have been done.
> 
> The good branch you should fork off is master.

OK, I did not know that. But then what I have are proposed updates, so
wouldn't it go there? It would be good if we came up with a short doc
somewhere, stating our bit branching model and how and where to prepare
patches. There are so many ways to do it and not everyone is a git
expert :).
 
> > I have not heard back from the previous set of patches, is there
> > interest to include them?
> 
> Sorry, I been away these days. Yes, topics that have proven to enhance
> OfflineIMAP in a good way (tested, etc) have good chances to be merged.
> There is sometimes good reasons to not keep a topic but it will always
> be discussed before and explaining why.

No problem, I hope you had some nice days at least (I spent those days
away being sick). So far, what I have is mostly stuff that I consider
cleanup, or nicer code architecture.

One thing I do not like so much for example, are the functions and
global variables that are currently being used outside of classes. I do
recognize that this might be a style issue but I like to have things
nicely encapsulated in classes.

> > and I plan to continue using them anyway, as I have started preparing
> > things for a test suite that can be run on offlineimap.
> 
> Nice. I like this idea. You may want to send your topics early or even
> in an experimental state. This would save you a lot of time if something
> goes wrong and will help people to keep track on your work.

Sure. Still thinking about how to do that best though. Maildir->Maildir
testing is easy locally, but for the IMAP synching, the tester needs to
set up a real (but unimportant and empty) IMAP account, I guess. I was
really just exploring the code base up to now, trying to grasp how
things really work.

> > Before delving any deeper into the threading things (ever noticed that
> > -d thread makes offlineimap coredump?), I would like to create a test
> > suite first. Have people here experience with python test suites?
> 
> Starting by the test suites is the best thing to do. This is where
> OfflineIMAP really fail, FMPOV.

Agree.

> I didn't open a issue trackers because I want to. Encourage people to
> use this mailing list is the best thing as it is where problems have
> most chances to hit someone which can help.

I agree that getting people to use the mailing list is a good thing. I
just find that mailing lists aren't really that good at keeping tabs
about which reported issues have been resolved and when.

To experiment a little, I created myself an issue tracker for keep tab
of the ideas I have at
http://offlineimap.lighthouseapp.com/projects/64962-offlineimap/tickets
which I will use for my purpose anyway. (login via OpenID) I find it
gives me a good overview compared to mailing lists and is quite
complementary. But time will time what tools are suited best.

> I'll look at your series.

Do look at the git branch over in my repo. I fixed one embarassing bug
in the ConfigParser patch and pushed it new. The one on the mailing
list

mail id:"1291046545-27856-3-git-send-email-Sebastian at SSpaeth.de"
[PATCH 03/17] Convert to use OptionParser for command line handling.

is obsolete.

Thanks.