future of OfflineIMAP [long]

[Nicolas Sebrecht]

On Fri, Jul 20, 2012 at 10:39:50PM +0200, Thomas Kahle wrote:
> Hi,
> 
> On 22:19 Thu 19 Jul 2012, Nicolas Sebrecht wrote:
> [...]
> 
> > IOW, the more valuable contributions we have ― each contributor doing a
> > few things ― the more we could still have OfflineIMAP supported. 
> > 
> > Here are some roles I'm thinking about:
> > - official and unofficial developers sending patches;
> > - official trusted maintainers (working in rotation?) to review and
> >   perhaps merge the patches;
> > - official testers validating patches for releases;
> > - one main official maintainer blindly pulling from trusted maintainers
> >   and doing the releases that contributors suggest.
> > 
> > Of course, such workflow would ask an isssue tracker.
> 
> I don't think that throwing more infrastructure at the problem will do
> any good.  For your setup there need to be at least 3 or 4 git gurus.
> Offlineimap is not the Linux kernel, what it needs is one dedicated
> person to merge patches floating on the mailing list and pick up the
> wrench her/him-self from time to time.

Notice this would be a infrastructure for a young team which has to
learn how to work alltogether. It would NOT be serious to exclude myself
or Sebastian to the process and open the release cycle to everybody
aiming to contribute.

So, we _need_ someone experimented with both OfflineIMAP and Git to make
releases for the moment. I'm fine with the job as long as it's possible
to do it the lazy mode.

Also, I talked about official testers because I know some users use
not-so-important IMAP accounts to test OfflineIMAP out there. Others
would enjoy testing OfflineIMAP with a test suites. And having official
testers involved in the release cycle would be wonderfull in the
long-term. No need to say why I prefer include them to the thread now.

>                                         In my opinion offlineimap does
> not need more features.  It just needs a little maintenance when things
> in python or imaplib change and bugs that are in the present features.

We can't make statements like that. Nobody know what will be the next
series of patches or what will be the amount of work required to merge
them, review, etc.
This is one of the main reasons why it is so hard to keep the maintainer
hat alone on a project like this one.

-- 
Nicolas Sebrecht