future of OfflineIMAP [long]

[Dave Abrahams]

on Thu Jul 19 2012, Nicolas Sebrecht <nicolas.s-dev-AT-laposte.net> wrote:

> Hi all,
>
> First of all, sorry for this long mail.
>
> I have to face to reality: currently I'm busy and I can't do much more,
> sadly. And I'm pretty sure that Sebastian is in a similar situation.
>
> I think I have to be honest. Maintaining OfflineIMAP like I (and
> Sebastian just after me) did looks compromised. But I would be really
> sad to announce that OfflineIMAP is discontinued, AGAIN.

+1.  I just went through the exercise of trying to escape from
OfflineIMAP and discovered that there's really nothing better out there.

> I've passed the last few mounths at tracking the mailing list for news
> and to keep aware of the activity around OfflineIMAP.  The good news is
> that we had developers sending patches, patches review, users testing
> software, regular contributors discussing about issues, etc. The main
> role we are missing is for maintenance tasks in a regular basis.
>
> I wonder if we could take a turn for maintenance and make all these
> contributions more valuable for the project.
>
> So, here is the idea that I have in mind: have more dispatched
> maintenance tasks with more official contributors. The idea would be
> to have contributors more involved in development and release cycles.
>
> IOW, the more valuable contributions we have ― each contributor doing a
> few things ― the more we could still have OfflineIMAP supported. 

+1

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

+1

> - official testers validating patches for releases;

Not so sure about this one.  How would the testers do this?  Nobody
wants to subject their important email to an alpha/beta system.

IMO the biggest missing thing is automated regression testing/continuous
integration.  It wouldn't be so hard to set up a system with a few
different IMAP servers, a free GMail account, and a Buildbot or a
Jenkins or something.  Without something like that, IMO, changes are
going to break things over and over.  Naturally, we also need tests.

> - one main official maintainer blindly pulling from trusted maintainers
>   and doing the releases that contributors suggest.

+1

> Of course, such workflow would ask an isssue tracker.

"Ask" doesn't quite make sense here in English.  Could you try saying it
differently?  Oh, if you mean "require"... we have an issue tracker
already at GitHub, don't we?

> Another thing: I suspect some people don't contribute much because of
> the work and knowledge it asks.
>
> If contribution were easy, I mean VERY easy, say without even the need
> to run git any command, would you contribute from time to time?

I am trying to contribute right now, and Git is the *opposite* of an
obstacle for me, so it wouldn't help *me* at all if you take Git out of
the workflow.  

You can actually create pull requests by submitting edits directly in
GitHub's web interface, so I think it actually *is* VERY easy, provided
you tell people what to do.  Just visit any file on GitHub and click the
"Edit" button.

> If so, maybe it would be of interest to write little scripts to make
> each task easier. For example, by role we could have:
>
> - ./contrib/patch.py: auto-magically commit changes, ask for a comment,
>   export patch and send it to the mailing list (or send a git pull
>   request, or even better, send changes to topic branches in the official
>   repository).
>
> - ./contrib/merge_patches.py: auto-magically fetch requested patches and
>   merge them in the correct branch and push result to the official
>   repository.
>
> - ./contrib/test.py: fetch last WIP or last RC and start testing.
>
> - ./contrib/release.py: fetch contributions from the current trusted
>   maintainer, auto-magically make a new release, update official
>   repository and make announce.
>
> - ./contrib/announce.py: let each trusted contributor send announces.
>
> I could start to write such scripts and prepare an announce for that if
> you think it worth.

I think building infrastructure for this stuff is premature.  Let's see
who wants to contribute.

> Also, what about improving documentation for contributors?

+1

> What to you think?

IMO these are the important ones:

* create a community of maintainers
* continuous integration
* more tests

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com