From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: master c6f03ed: Fix a problem in url.el without GnuTLS Date: Sun, 14 Dec 2014 09:46:12 -0800 Organization: UCLA Computer Science Department Message-ID: <548DCCE4.905@cs.ucla.edu> References: <20141211155740.11916.1584@vcs.savannah.gnu.org> <87ppbquo97.fsf@gmail.com> <83zjaurreb.fsf@gnu.org> <874mt14wrc.fsf@lifelogs.com> <83egs5rzlr.fsf@gnu.org> <877fxx2e6t.fsf@lifelogs.com> <83a92trlgs.fsf@gnu.org> <87oar81jlp.fsf@lifelogs.com> <87bnn7rkcq.fsf@engster.org> <877fxvri96.fsf@engster.org> <87zjarznzs.fsf@lifelogs.com> <87sigjpri2.fsf@engster.org> <838uib60jv.fsf@gnu.org> <87mw6rpc6l.fsf@engster.org> <83sigj48z5.fsf@gnu.org> <874mszp2i7.fsf@engster.org> <83iohe43hu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1418579229 23334 80.91.229.3 (14 Dec 2014 17:47:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 14 Dec 2014 17:47:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 14 18:47:02 2014 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 1Y0DG1-0002kn-Er for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 18:47:01 +0100 Original-Received: from localhost ([::1]:36725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0DG1-0005iT-42 for ged-emacs-devel@m.gmane.org; Sun, 14 Dec 2014 12:47:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0DFh-0005iH-GU for emacs-devel@gnu.org; Sun, 14 Dec 2014 12:46:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y0DFa-0001CK-1Z for emacs-devel@gnu.org; Sun, 14 Dec 2014 12:46:41 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:48939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y0DFS-0001BF-3S; Sun, 14 Dec 2014 12:46:26 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 1B4E739E801A; Sun, 14 Dec 2014 09:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+bY7Lm1yYtG; Sun, 14 Dec 2014 09:46:16 -0800 (PST) Original-Received: from [192.168.1.9] (pool-71-177-17-123.lsanca.dsl-w.verizon.net [71.177.17.123]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 406EFA60011; Sun, 14 Dec 2014 09:46:16 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: <83iohe43hu.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 131.179.128.62 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:180098 Archived-At: Eli Zaretskii wrote: > perhaps we need to radically rethink > our recommended project workflow, like not base it on merges but on > rebase, or push fixes to master and then cherry-pick them to the > release branch, or something else Part of the problem is the mundane business of maintaining ChangeLogs by hand, an error-prone process with merges. We're planning to fix this (currently scheduled for next month) by generating ChangeLogs automatically. Perhaps once we've done that the remaining problems with merging will be so small that we can just live with them. (The particular problem Ted ran into seems pretty complicated; I'm not sure it's a good use case for us when designing our development workflow.) More fundamentally there's the issue of how much we want commits to be serialized. That is, do we want development history to look as if it was done one commit at a time in a single branch? If so, merges are not the way to go, because they're DAG-based.