From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: gnulib strftime imported into Emacs Date: Mon, 31 Jan 2011 10:44:09 +0100 Message-ID: References: <4D45F788.1020101@cs.ucla.edu> <83r5btg1td.fsf@gnu.org> <4D466C8D.2020102@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1296467333 32447 80.91.229.12 (31 Jan 2011 09:48:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 31 Jan 2011 09:48:53 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 31 10:48:49 2011 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 1PjqNM-0000co-8p for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 10:48:48 +0100 Original-Received: from localhost ([127.0.0.1]:44611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjqNL-0005md-FE for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 04:48:47 -0500 Original-Received: from [140.186.70.92] (port=59450 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PjqJA-0003vG-P1 for emacs-devel@gnu.org; Mon, 31 Jan 2011 04:44:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PjqJ9-0006Cf-EX for emacs-devel@gnu.org; Mon, 31 Jan 2011 04:44:28 -0500 Original-Received: from iwfs.imcode.com ([82.115.149.64]:46471 helo=gate.verona.se) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PjqJ7-0006Ak-Fy; Mon, 31 Jan 2011 04:44:25 -0500 Original-Received: from chopper (IDENT:1005@localhost [127.0.0.1]) by gate.verona.se (8.13.4/8.11.4) with ESMTP id p0V9iAUt005699; Mon, 31 Jan 2011 10:44:10 +0100 In-Reply-To: <4D466C8D.2020102@cs.ucla.edu> (Paul Eggert's message of "Mon, 31 Jan 2011 00:02:21 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-Received-From: 82.115.149.64 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:135285 Archived-At: Paul Eggert writes: > On 01/30/2011 08:00 PM, Eli Zaretskii wrote: > >> Could we please talk before making such disruptive changes in the >> future? > > We did talk; for example, > .I thought this was enough, but apparently I was mistaken. > >> Ideally, Windows related changes should be committed to the >> repository at approximately the same time as the changes for Posix >> platforms, but that's only possible if you let me see the changes >> _before_ they are committed, and if we coordinate the commit to happen >> when I have time to work on that. Is such cooperation possible? > > I worry that this would mean that every time I want to make a > nontrivial change to a makefile, I would have to run the exact change > by you first. And, as you say, you don't have much free time, and can't be > expected to respond quickly; it might need to wait until the next weekend, > say. That wouldn't be a good recipe for development; it would slow things > down too much on the trunk. > > If this turns into a continuing problem, perhaps it would be better to establish > a branch for Microsoft-related platforms, and to merge changes from the trunk > into that branch whenever you have time. People could then do Microsoft builds > from that branch. > >> It also means that Tom will have to wait for yet another week with his >> threading related changes > > Sorry, I don't get the connection. Tom can't put in his threading > related changes until Emacs builds on Microsoft platforms? Emacs doesnt seem to have a spelled out policy but the following approach is liked by many projects: - commits to trunk should not knowingly break compilation - feature development occurs on branches and are merged to trunk when apropriate The problem with this approach for Emacs is that it is very difficult to test all configurations, so one can't be very sure even seemingly trivial changes wont break compilation. I have a Hudson continuous build server for Emacs now, building a couple of branches on Fedora 14. I intend to set up a couple of more build slaves for different platforms. I can reasonably expect to be able to provide slaves for a couple of gnu/linux distributions, windows, dos, osx, and some ARM based platform. This won't happen soonish so it won't solve short term issues. Anyway, in the end it will be possible for a developer to be reasonably sure a feature branch wont break trunk builds on any supported platforms when merged. I'm aware that this subject is somewhat sensitive and there are various opinions how trunk should be used etc. I'm not claiming a mandate to enforce a policy, only offering to provide a service to enable a particular strategy that doesn't exclude others. -- Joakim Verona