[PATCH 07/17] Re: Rework lock/pidfile. Make ui class var of OfflineImap

[Nicolas Sebrecht]

On Thu, Dec 02, 2010 at 11:50:28AM +0100, Sebastian Spaeth wrote:
> On Wed, 01 Dec 2010 23:47:22 -0600, Rob Browning wrote:
> > Sebastian Spaeth <Sebastian at SSpaeth.de> writes:

> > Perhaps I misunderstand, but wouldn't it be safer to continue using the
> > same lock file, and just print a warning (explaining how to fix the
> > problem) and exit if the lock file exists? i.e.:
> > 
> >   $ offlineimape
> >   ERROR: exiting because foo/lock exists.  If you are *certain* that
> >   offlineimap is not running, please delete the file and try again.
> ...
> > I'm just wary of the approach described above because it sounds like the
> > failure case could be catastrophic with respect to the user's data.
> 
> As the new offlineimap would store its LocalStatus in an sqlite
> database, and the old one in plain old textfiles, one can not go back
> and forth between older (aka 0.6.2) and newer versions, there is no
> forward-compatability in 0.6.2.

Not exactly but the misconception is my fault since I still didn't
explain the workflow.

Rob's comment makes sense because the SQL topic is _not_ ready to be
merged as is. It will need more work before inclusion to a release. Here
is a quick documentation of the (new) topic oriented workflow we are
going to use.

master, next and pu are the three main branches:

- master is the mainline. This is where release happen. Trivial patches
  and bug fixes could be directly applied here too. Developers usually start
  forking off of this branch to implement stuff.
- next stores topics meant to be merged in the next release. This
  does NOT mean that all patches will be included but that
  they have good chances to be. This is where developers do the tests on
  new topics before they are released.
- pu only stands to track on interesting topics. Topics here are not
  ready to be granted to next so they won't be included to the next
  release.

I'll do a more precise and detailed documentation on this for the coming
week. Notice that this worflow is not my idea. I've stolen it from other
projects such as the Git project itself.

> Using the same lockfile name would have no different effect but that the
> user has to delete the existing one manually the first time he runs a
> newer offlineimap.
> 
> not sure what the best strategy is...

I didn't check why change the lockfile so I may have missed something
trivial but this has to be motivated first.  A good place for this is
the commit message.

Both strategies are applicable. That said, if there is an incompatible
change, it will have to be documented (to distribution maintainers and
users) an wait until the next _major_ release.

-- 
Nicolas Sebrecht