From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 08AF16DE0355 for ; Tue, 9 May 2017 10:09:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.057] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mha3IA_Ln-jj for ; Tue, 9 May 2017 10:09:13 -0700 (PDT) X-Greylist: delayed 368 seconds by postgrey-1.36 at arlo; Tue, 09 May 2017 10:09:13 PDT Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTP id 278C06DE0352 for ; Tue, 9 May 2017 10:09:13 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id C1155F993; Tue, 9 May 2017 13:03:03 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id B91E62126D; Tue, 9 May 2017 13:02:17 -0400 (EDT) From: Daniel Kahn Gillmor To: David Bremner , Jeffrey Stedfast , "notmuch\@notmuchmail.org" Cc: notmuch@freelists.org Subject: RE: Upcoming GMime 3.0 changes In-Reply-To: <87k25q178l.fsf@tesseract.cs.unb.ca> References: <87mvcom1z8.fsf@tethera.net> <87k25q178l.fsf@tesseract.cs.unb.ca> Date: Tue, 09 May 2017 13:02:17 -0400 Message-ID: <87shkeklpi.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 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: Tue, 09 May 2017 17:09:14 -0000 On Tue 2017-05-09 10:37:30 -0300, David Bremner wrote: > Just for the record, I have some patches in progress for porting to > gmime-3.0. The main issue is the multiplicity of memory management > models involved. I think the gmime 3.0 approach of using more stock glib > memory management makes sense, but it will require a bit of work to make > code that can compile against gmime-2.6 and gmime-3.0. I don't see us > being able to drop support for gmime-2.6 for a few years, unfortunately. out of curiosity, why do you think we won't be able to drop gmime-2.6 for a few years? if it's due to the debian release cycle and wanting to backport notmuch to stretch, i don't think i'd mind providing backports of gmime 3.0 for that purpose. --dkg