Patches updated to nicolas/pu

[Nicolas Sebrecht]

On Wed, Dec 01, 2010 at 09:57:48AM +0100, Sebastian Spaeth wrote:
> > On Mon, Nov 29, 2010 at 04:05:51PM +0100, Sebastian Spaeth wrote:

> OK, I did not know that. But then what I have are proposed updates, so
> wouldn't it go there?

No because the merge is a maintainer work. Maintainers merge what they
think is OK and decide where to merge topics but the help of developers is
appreciated, of course.

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

Yes, this is what I want to do first, with adding personal informations
and so in the first coming release. I think it will be done this
week-end.

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

This usualy is a good design. Let's talk in patches. ,-)

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

True. May be we could:

  - set up a minimal IMAP server in the tests

or

  - use a minimal dedicated configuration file (account informations)
    that would be merged in the configuration file used by the tests.

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

This rely on how you use your mailbox. I don't think this would cause
much problems. Notice this is how Git project works, for example. This
help to talk in patches everywhere we should.

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

You can use or start you own tracking system if you want to. I'm NOT
against this idea. If users and developers naturally use it I'm
inclined to use it too. Fow now, I think the mailing list is enough and
better.

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

So, resend it. Let other developers track you without much pain. You
will gain more reviewers, help and contributions.

-- 
Nicolas Sebrecht