From 3837627db20b3146caa03e74cfc0174418db9d87 Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Sun, 17 Nov 2013 17:28:09 +0200 Subject: [PATCH] Re: [PATCH v2 5/5] compact: provide user more information on after-compaction failures --- a1/28f3503caeb40cede8d572eaf6cfcb00504197 | 106 ++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 a1/28f3503caeb40cede8d572eaf6cfcb00504197 diff --git a/a1/28f3503caeb40cede8d572eaf6cfcb00504197 b/a1/28f3503caeb40cede8d572eaf6cfcb00504197 new file mode 100644 index 000000000..8c95be90b --- /dev/null +++ b/a1/28f3503caeb40cede8d572eaf6cfcb00504197 @@ -0,0 +1,106 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 1AA51429E30 + for ; Sun, 17 Nov 2013 07:28:27 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 4OmqkeZ4UPlh for ; + Sun, 17 Nov 2013 07:28:16 -0800 (PST) +Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34]) + by olra.theworths.org (Postfix) with ESMTP id B2070429E27 + for ; Sun, 17 Nov 2013 07:28:16 -0800 (PST) +Received: from guru.guru-group.fi (localhost [IPv6:::1]) + by guru.guru-group.fi (Postfix) with ESMTP id 784E9100030; + Sun, 17 Nov 2013 17:28:09 +0200 (EET) +From: Tomi Ollila +To: David Bremner , Jani Nikula , + notmuch@notmuchmail.org +Subject: Re: [PATCH v2 5/5] compact: provide user more information on + after-compaction failures +In-Reply-To: <8738mvz2fy.fsf@zancas.localnet> +References: <1384362167-12740-1-git-send-email-tomi.ollila@iki.fi> + <1384362167-12740-6-git-send-email-tomi.ollila@iki.fi> + <871u2jnkai.fsf@nikula.org> <87y54rx8sf.fsf@unb.ca> + + <8738mvz2fy.fsf@zancas.localnet> +User-Agent: Notmuch/0.16+174~g9a06aa2 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-unknown-linux-gnu) +X-Face: HhBM'cA~ +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 17 Nov 2013 15:28:27 -0000 + +On Sun, Nov 17 2013, David Bremner wrote: + +> Tomi Ollila 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 -- 2.26.2