From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: GIT mirror of Lisp dev sources [was: Char-folding: how can we implement matching...] Date: Tue, 01 Dec 2015 12:29:36 -0600 Message-ID: <8737vm2fan.fsf@red-bean.com> References: Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1448994613 5109 80.91.229.3 (1 Dec 2015 18:30:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Dec 2015 18:30:13 +0000 (UTC) Cc: Eli Zaretskii , bruce.connor.am@gmail.com, emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 01 19:30:07 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a3pgb-00039s-Jf for ged-emacs-devel@m.gmane.org; Tue, 01 Dec 2015 19:29:57 +0100 Original-Received: from localhost ([::1]:54318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3pga-0007Mw-VM for ged-emacs-devel@m.gmane.org; Tue, 01 Dec 2015 13:29:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3pgN-0007Mm-KL for emacs-devel@gnu.org; Tue, 01 Dec 2015 13:29:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a3pgI-0004zj-LT for emacs-devel@gnu.org; Tue, 01 Dec 2015 13:29:43 -0500 Original-Received: from mail-ig0-x229.google.com ([2607:f8b0:4001:c05::229]:34458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a3pgI-0004zd-Hd; Tue, 01 Dec 2015 13:29:38 -0500 Original-Received: by igvg19 with SMTP id g19so100605763igv.1; Tue, 01 Dec 2015 10:29:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=E74xBKvVsjZL/KT+xtq0ddd83Wd7Yto8bRuppMEAeCE=; b=EyNgZzKjM0x583La81racSGYZKNIeKrb6tKIRyqRGeEyTXm65RoVcnkWQuAjDMlxO5 uUrUb+c251YYE8HF+CYg3f2msPIBD79nIqGXazgU8NQViiCagLyyN3+Ny3OP1e0dku3x PlBHYhAA5hOXlSIJSK6AetkwpXamQk1yrUse51Ksc15abrFXztI7DAAisrpskCaJpwgJ d5FTUKISJqEjxGq2/jS3jdmIcm6IaGZFmPb64eTlX/D0lyHzwbeYfSINzonwzizFXhNW WB/c1Z5I3ptBotVZgVYL7IKgl1ZYt8mu3lF+UyTVWtJQaRJRuDErOnrz9bAAn89b2rGr k5iw== X-Received: by 10.50.160.33 with SMTP id xh1mr26798495igb.25.1448994577995; Tue, 01 Dec 2015 10:29:37 -0800 (PST) Original-Received: from floss (74-92-190-114-Illinois.hfc.comcastbusiness.net. [74.92.190.114]) by smtp.gmail.com with ESMTPSA id o86sm19680095ioi.36.2015.12.01.10.29.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2015 10:29:37 -0800 (PST) In-Reply-To: (Drew Adams's message of "Tue, 1 Dec 2015 10:03:32 -0800 (PST)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4001:c05::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:195694 Archived-At: Drew Adams writes: >(Why doesn't master hold the latest developments, just as >(IIUC) it has always done in the past?) During release stabilization, at least in recent releases that I can remember, the maintainers have asked that changes go to the release branch first and then get (automagically or semi-automagically) ported to 'master' later. So that's what we've been doing for a while. I think it's partly just to ensure that what's about to be released gets live-tested as much as possible by the developers. I don't know when this release branch policy was first instituted, and am not suggesting that it's better or worse than a master-first policy. But it's what we've been doing. IIRC John W. speculated that we might do differently for the next release, but said he didn't want to change it for this release. I don't remember which email I saw that in, though. Best regards, -Karl