Re: [PATCH v2 5/5] compact: provide user more information on after-compaction failures

[Tomi Ollila <tomi.ollila@iki.fi>]

On Sun, Nov 17 2013, David Bremner <david@tethera.net> wrote:

> Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> The log hook in it's current form is problematic as it doesn't provide
>> way to distinguish progress reporting from error reporting.
>
> Is this _more_ problematic than more output to stderr?
>
>>  Currently
>> lib/database.cc writes error messages with fprintf(stderr, ...) everywhere.
>
> Sure. But I'm trying to understand why a partial fix isn't better than
> nothing.  Is the argument just that the effort is wasted, or that the
> result is somehow less satisfactory than the status quo.

The partial fix (using current log hook) would mean we either write all
messages to stdout or to stderr.

To the end user this would mean inconsistent behaviour in compact compared
to other commands (like 'notmuch new' which prints progress to stdout and
errors to stderr).

I personally think doing things this way for 0.17 is tolerable
(considering current schedule and risks involved) so that user experience
is stable.

>> I suggest that this problem is fixed in one big sweep during 0.18
>> development -- the suggestion Jani pastebin'd a few days ago is
>> a good one and I'm willing to take part of that development...
>> And now take this approach of fprintf()ing (basically I would
>> also ask developers using the library wait for 0.18 before starting
>> to use the compact functionality (if ever), as the we have yet
>> another soname bump with changing interface coming...
>
> I guess we can mark this interface as unstable for the moment?
> "Asking developers not to use it" sounds pretty bad.

I was thinking naming the function notmuch_database_compact_internal ()
as one option (I also though of notmuch_database_compact_unstable () -- but
that sounds so "unstable" (at least outside Debian people ;D)) --
could be one option. Then developers should understand the API is not
fixed there...

Although "Informing developers to prepare for upcoming changes to the API"
(which is goind to happen early on 0.18 development cycle) should suffice.

> d

Tomi