[PATCH 0/13] Re: Reintegrate imaplib2 and IDLE, again

[Nicolas Sebrecht]

On Mon, Feb 07, 2011 at 02:28:13PM -0500, Ethan Glasser-Camp wrote:
> On 02/07/2011 07:43 AM, Sebastian Spaeth wrote:
> 
> >I agree that this should go into some mainline branch soon. But I would
> >propose to merge the APPENDUID branch and release that one as a proper
> >release first. It fixes the mangling of emails in many cases and the
> >handing of the wrong date to the mail server in nearly all cases.
> >
> >If we release that and integrate the IDLE branch than, it will be easier
> >to find out which branch is responsible for breaking things and it would
> >be easier to revert the IDLE branch if it were responsible for breaking
> >things.
> 
> I agree. I don't care too much about when IDLE hits master, I just
> want to know that if I get super busy again for a few months, it
> won't get forgotten :)

Let me be a bit more clear.

I'm not in favor to have such feature merged as is too fast since it
could make a lot of damages. The condition I made for doing so is to
have it _optional_ and marked as _experimental_.

We all agree it should be tested efficiently before having it as a full
maintained and provided feature. The main problem is the /how/ to
achieve this part. The best alternative is to have it widely tested by
users on a large panel of systems and situations. This is why we really
should have it merged _soon_.  Users and testers _won't_ merge anything
to help in this task. Let us do this work for them. Once included,
they'll enjoy to test the "new killing feature" they were missing.

There is another good reason why it should hit the mainline soon (still
if both prerequisites are granted): long-lived branches are _NIGHTMARE_.

The mainline won't be sleeping and waiting for such branches. While the
mainline live, long-living branches have to be updated off. It means
large rebases again and again. So, an efficient move in mainline with no
regards for unmerged stuff can be annoying and dramatic for thoses
branches.  Features are drawn against a code at a certain stage, having
a given design, drawbacks etc. A feature likely comes with _all_ of that
in mind. While days pass, this becomes wrong and the feature (by design,
concordance, etc) can't match the mainline as nicely as it was on its
first ages.

If the feature is merged soon, the mainline can't ignore that code (it
is part of it). It helps raising compatibility and design issues ASAP,
and as a consquence help doing the right decisions for the mainline
progress.

Please don't think in terms of long-living branches, it's a bad thing
for the quality of the code and our workload. Think in terms of
long-living experimental/testing features.

  Notice that this is what's happening for the SQL feature. In some
  time, I'll even eject that topic from pu. Making the SQL feature an
  experimental option should not be that hard for now but it is going to
  be obsolete from the concordance point of view.

Release soon, release often.


-- 
Nicolas Sebrecht