bug in offlineimap 6.2.0 (Arch Linux package)

[Nicolas Sebrecht]

On Fri, Jan 28, 2011 at 10:49:10AM +0100, Sebastian Spaeth wrote:
> On Fri, 28 Jan 2011 10:11:36 +0100, Kevin Brubeck Unhammer wrote:
> 
> > sorry if this has been reported already, but I get a bug in the current
> > release 6.2.0 (Arch Linux).
> 
> This is still present in 6.3.1 but has been fixed in v6.3.2-rc1 already.
> So you either need to install an updated version locally, or wait for
> the next release to hit Arch :-).
> 
> @Nicolas: Can we cherry-pick the "Remove MultiLock implementation" patch
> which is in next into master before releasing? Otherwise we will have
> the Curses ui is broken regression in that release. I know, you already
> released rc2, but this patch avoids a regression.

I didn't merge it in master because it's Curses UI dedicated, meaning
that it's not breaking offlineimap: changing to the best, well tested
and prior maintained UI is fine. Plus, we are in a -rc state wich really
means some things may be broken.

So no, I'm not going to merge the topic to master.

> Should we then focus on getting master out as a new release before
> making more major changes?

When I decide to make a new release I just merge the content of next
into master and then tag the history. You can see next as the staging
area for topics we'd like to have in the next release. next is usually
the branch testers (and developpers) are using on their own data.

I may merge some trivial patches (or very important fixes) directly to
master.  But it's not a good thing to do for other topics. Otherwise, it
would mean they appear in the mainline _without_ any chance to be
tested.

Currently, we are in a -rc (release candidate) release cycle. It means
efforts (since the first -rc) have to go to make the coming release as
stable as possible. Efforts focus on next.

In real life, things aren't _that_ obvious: fixes may introduce dramatic
breakages, and features may silently fix issues. That's why it's
increasing: the more we go on -rc, the more we focus on tests, the more
I merge fixes only. For some projects (Linux, Git, FreeBSD) a feature
topic beeing sent in a release candidate cycle is _very not_ welcome.
Again, we aren't so drastic, even if we try to make things good (using
proven engineering cycle).

Topics introducing features, changes, etc are welcome while on a stable
release.

Hope it answers your question. If not, let me know.

-- 
Nicolas Sebrecht