From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Keeping changes in sync with upstream projects Date: Tue, 18 May 2010 16:55:48 -0400 Message-ID: References: <86zkzxccfw.wl%lluis@ginnungagap.pc.ac.upc.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1274216268 13401 80.91.229.12 (18 May 2010 20:57:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 18 May 2010 20:57:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Llu=EDs?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 18 22:57:47 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OETqK-00061n-B9 for ged-emacs-devel@m.gmane.org; Tue, 18 May 2010 22:57:47 +0200 Original-Received: from localhost ([127.0.0.1]:54349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OETps-000305-0U for ged-emacs-devel@m.gmane.org; Tue, 18 May 2010 16:56:20 -0400 Original-Received: from [140.186.70.92] (port=35060 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OETpQ-0002h1-FK for emacs-devel@gnu.org; Tue, 18 May 2010 16:56:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OETpN-0007q9-4U for emacs-devel@gnu.org; Tue, 18 May 2010 16:55:50 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:29471 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OETpN-0007q3-2D for emacs-devel@gnu.org; Tue, 18 May 2010 16:55:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIOb8ktMCpz0/2dsb2JhbACeA3K+b4UQBIwv X-IronPort-AV: E=Sophos;i="4.53,257,1272859200"; d="scan'208";a="64512654" Original-Received: from 76-10-156-244.dsl.teksavvy.com (HELO pastel.home) ([76.10.156.244]) by ironport2-out.pppoe.ca with ESMTP; 18 May 2010 16:55:48 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 0FE9C8079; Tue, 18 May 2010 16:55:48 -0400 (EDT) In-Reply-To: <86zkzxccfw.wl%lluis@ginnungagap.pc.ac.upc.edu> (=?iso-8859-1?Q?=22Llu=EDs=22's?= message of "Tue, 18 May 2010 20:05:55 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124912 Archived-At: These are very good questions, thanks for asking. The Gnus guys have their own answer to that (not sure how advanced it is by now), so maybe they could say how well it works for them. The 2-way sync is the harder part. And doing it *with* differences (aka "discarded/held changesets"), it's even worse. So I think the right course of action is something like: - start with 4 version of the code: [upstream] <-> [clean upstream] <-> [clean Emacs] <-> [Emacs] where "clean upstream" means "upstream without the patches that shouldn't make it into Emacs" and "clean Emacs" means "Emacs without the changes that shouldn't make it into upstream". I.e. [clean upstream] and [clean Emacs] should be virtually identical, except maybe for file layout and VCS. - first simplification: reject Emacs patches that can't make it into upstream. I.e. enforce [clean Emacs] == [Emacs]. That means that when an Emacs patch is unacceptable upstream, it needs to be resolved somehow: either one side convinces the other, or the patch needs to be reworked. Typically such changes are linked to features that don't exist/work in XEmacs or in older Emacsen, so the problem can resolved by adding compatibility code. - second simplification: don't install into [upstream] patches that should make it into Emacs; instead install them into [clean upstream]. - the flow is now limited: [upstream] <- [clean upstream] <-> [Emacs] - so [upstream] is basically a normal feature-branch that tracks the "trunk" aka [clean upstream]. Any DVCS will handle that just fine. - so all that's left is the core 2-way sync. I don't know of any easy/right way to do that. - of course, the best is to add a third simplification: let upstream use [Emacs] for development, so the "2-way" sync is a nop. Stefan