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: Avoiding slowdown in trunk development Date: Tue, 01 Feb 2011 11:04:44 -0800 Organization: UCLA Computer Science Department Message-ID: <4D48594C.3070900@cs.ucla.edu> References: <4D45F788.1020101@cs.ucla.edu> <83r5btg1td.fsf@gnu.org> <4D466C8D.2020102@cs.ucla.edu> <4D473584.6010205@cs.ucla.edu> <838vy0flgh.fsf@gnu.org> <4D47B17C.6080201@cs.ucla.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1296588387 2651 80.91.229.12 (1 Feb 2011 19:26:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Feb 2011 19:26:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 01 20:26:22 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 1PkLro-00067t-Au for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 20:26:21 +0100 Original-Received: from localhost ([127.0.0.1]:53584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkLXH-0002Ru-4n for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 14:05:07 -0500 Original-Received: from [140.186.70.92] (port=38868 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkLXA-0002RD-Ka for emacs-devel@gnu.org; Tue, 01 Feb 2011 14:05:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkLX1-0007re-R3 for emacs-devel@gnu.org; Tue, 01 Feb 2011 14:04:52 -0500 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:60445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkLWx-0007p4-P1; Tue, 01 Feb 2011 14:04:48 -0500 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 73C6A39E80E1; Tue, 1 Feb 2011 11:04:45 -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 P5+jlCLvvvV8; Tue, 1 Feb 2011 11:04:44 -0800 (PST) Original-Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 9A1BD39E80DC; Tue, 1 Feb 2011 11:04:44 -0800 (PST) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 In-Reply-To: X-Enigmail-Version: 1.1.2 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:135416 Archived-At: On 02/01/11 00:58, Eli Zaretskii wrote: > A couple of possible workflows come to mind: Both of those suggestions would take more developer time. For example, I might have to figure out which changes to cherry-pick from other codelines and would have to deal with merge conflicts. I often do this sort of thing, but it consumes valuable think time and context-switching time (i.e., the context inside my head :-) to maintain a separate line of development. It's more efficient to avoid that when possible, as is the case here. > But I don't see how a couple of days of delay could possibly be of any > practical importance; do you? Sure they can. Either they slow down that line of development a couple of days, which is bad in real-time, or they require more context-switching and merging, which is bad in developer-time. > There are many other projects with more > disciplined commit policies, where e.g. a commit requires an a-priori > approval; surely it doesn't mean those projects are unduly slowing > down their development? There are many reasons why projects might need a change control board or similar mechanism. Such mechanisms almost invariably slow down development. If they're needed anyway, despite that disadvantage, then they are slowing down development for good reason. But that's not the case here. The special needs of the Windows port are not a good reason to slow down mainline development. >> > if that commit fails due to a nearly-simultaneous >> > trunk commit by someone else, I typically just revert my copy of the >> > trunk and start over. > I hope by "revert" you meant "bzr up", not "bzr revert". The short > time window for the kind of race condition that could happen in this > situation will rarely cause changes in parts that are related to your > changes. Near-simultaneous changes have caused problems for me. bzr may be good at merging, but its errors are common enough to be of concern to me. So I take a more cautious approach using "bzr revert". This approach has not caused problems. At any rate, I don't see how that caution is relevant. No matter which bzr style one uses to merge changes, the main problem is the hassle of merging, not the bzr style one uses to merge. >> > The Windows port should not require mainline developers >> > to spend significant chunks of their time. > How is this different from spending time on fixing problems of other > proprietary platforms, e.g. Solaris? It is greatly different as a practical matter. Solaris is quite easy to port to, and mainline development is not significantly impeded by concerns about a Solaris port. In contrast, Windows is not nearly as easy to port to, and concerns about the Windows port are getting in the way of mainline development. > Please also note that in Emacs, most of the development happens in > platform-independent and device-independent parts, so people who track > the development trunk are not used to breakage that affects a single > platform. In that case, perhaps all that's needed is a minor adjustment in expectations. When Emacs's platform-independent parts are being changed, Windows developers can continue to expect Emacs to build. When the platform-dependent parts change, they can expect builds to fail temporarily, until someone who's versed in Windows adjusts the Windows build procedure. This approach is quite common in other projects, and it works for Emacs as well.