From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: gnulib strftime imported into Emacs Date: Tue, 01 Feb 2011 06:05:50 +0200 Message-ID: <838vy0flgh.fsf@gnu.org> References: <4D45F788.1020101@cs.ucla.edu> <83r5btg1td.fsf@gnu.org> <4D466C8D.2020102@cs.ucla.edu> <4D473584.6010205@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1296533545 14960 80.91.229.12 (1 Feb 2011 04:12:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 04:12:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 05:12:10 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 1Pk7aU-0006SQ-69 for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 05:12:09 +0100 Original-Received: from localhost ([127.0.0.1]:51745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pk7V8-0006Wm-4R for ged-emacs-devel@m.gmane.org; Mon, 31 Jan 2011 23:05:58 -0500 Original-Received: from [140.186.70.92] (port=38458 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pk7V3-0006Vm-B8 for emacs-devel@gnu.org; Mon, 31 Jan 2011 23:05:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pk7V1-00042E-Lw for emacs-devel@gnu.org; Mon, 31 Jan 2011 23:05:52 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:51063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pk7V1-000420-FU for emacs-devel@gnu.org; Mon, 31 Jan 2011 23:05:51 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LFX00G0076RM300@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Tue, 01 Feb 2011 06:05:49 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.124.97.124]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LFX00GNH7DOCO90@a-mtaout21.012.net.il>; Tue, 01 Feb 2011 06:05:49 +0200 (IST) In-reply-to: <4D473584.6010205@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.169 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:135378 Archived-At: > Date: Mon, 31 Jan 2011 14:19:48 -0800 > From: Paul Eggert > CC: emacs-devel@gnu.org > > On 01/31/11 03:06, Eli Zaretskii wrote: > > > I'm talking only about changes that are known in advance to break > > some platform, and for which you are not providing the corresponding > > changes as part of the changeset. I'm asking whether it would be > > possible to talk a short while before committing such changes, > > Sure, I can send out some email when I'm coding up changes. It should > be easy to do that, as part of normal development. Thanks, this should make things easier and more smooth. > > when you already have your feature branch ready to merge onto the trunk. > > This part sounds too strict, though. Normally it takes quite some > time to prepare the change precisely for the trunk. I understand that this is because you don't actually build on your feature branches, but instead merge onto the trunk first, and build there. IMO, that's an inefficient workflow when using a dVCS. If you would build your feature branches, then merging onto the trunk would be an easier job, that basically boils down to a short test of your changes with the latest mainline code. That testing does not need to repeat all the elaborate tests you did on a branch, because a few days worth of Emacs development cannot change the code too much. > > If the change needs non-trivial corresponding changes in the Windows > > build process, I might indeed ask to wait a few days. > > This part worries me. Mainline Emacs development shouldn't be held > back because of a lack of resources to port it to Windows. You could port it yourself. Most of the changes are trivially ported, especially for someone who knows such a great deal about gnulib. > > Emacs 24 is still very far from a release, so why is it important to > > commit changes urgently (except changes that fix bad bugs)? > > Because we want it as easy as possible to make improvements to Emacs. As easy as possible, but no easier. > > We are using a dVCS now, so waiting with a changeset should not slow > > down others, nor even you yourself, with any further development. > > Yes it would, because it would cost more integration and testing time, > for mainline developers. Also it would slow us down in making further > improvements that depend on earlier improvements. Using feature branches better should all but eliminate this difficulty. > The burden of integration and testing for Windows platforms should > be on the people contributing to the Windows ports, not on mainline > developers. I never requested anything else. But a bit of cooperative spirit won't hurt anyone.