From: Pieter Praet <pieter@praet.org>
To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>,
	David Bremner <david@tethera.net>, notmuch@notmuchmail.org
Subject: Re: [PATCH v2] Output unmodified Content-Type header value for JSON
	format.
In-Reply-To: <87obw6prpd.fsf@gmail.com>
References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
	<1321676321-27745-1-git-send-email-dmitry.kurochkin@gmail.com>
	<87sjlktgi6.fsf@zancas.localnet> <87obw6prpd.fsf@gmail.com>
User-Agent: Notmuch/0.10.2+115~gadd29f6 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Thu, 12 Jan 2012 18:08:08 +0100
Message-ID: <87fwfkluh3.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Sun, 20 Nov 2011 22:35:42 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> On Sat, 19 Nov 2011 08:59:29 -0400, David Bremner <david@tethera.net> wrote:
> > On Sat, 19 Nov 2011 08:18:41 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
> > > Before the change, notmuch used g_mime_content_type_to_string(3)
> > > function to output Content-Type header value.  Turns out it outputs
> > > only "type/subtype" part and ignores all parameters.  Also, if there
> > > is no Content-Type header, default "text/plain" value is used.
> > 
> > Hi Dmitry;
> > 
> > I haven't analyzed the substance of your patch yet, but I did have a
> > couple thoughts while reading your mail.
> > 
> > - It seems that every time we change the json format, we have a round of
> >   suffering because people are unable to detect a mismatch between their
> >   emacs code and the cli. Not that this is your problem necessarily, but
> >   it would be nice if someone (TM), would come up with some version info
> >   for the json output, and a patch to check it on the emacs side.
> > 
> 
> IMO this is a good idea.
> 
> > - The previous point is a bit of a counterargument to this, but in
> >   general, I think I prefer patches that modify the core seperate from
> >   those that do emacs (or python, or ...) stuff.
> > 
> 
> I couls separate it.  I made is a single patch to avoid having a
> revision with broken emacs UI (and tests).
> 

I'd like to propose to always apply patch series on a *topic* branch
which would then be merged back into 'master', thus avoiding this issue
altogether whilst making it more obvious which patches belong together
(eg. for easier cross-referencing with the ML).

> Regards,
>   Dmitry
> 
> > - I understand you want to make your patches reviewable without applying
> >   by including lots of context, but at a certain point it has actually
> >   the opposite effect for me. I just don't read 900+ line emails ;). Of
> >   course, I can still apply the patch and look at it, so it's really up
> >   to you.
> > 
> > d
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter