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: Reordering etc/NEWS Date: Fri, 11 May 2007 11:50:28 +0300 Message-ID: References: <2wmz0iriyj.fsf@fencepost.gnu.org> <876470ekuz.fsf@red-bean.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: sea.gmane.org 1178873445 10761 80.91.229.12 (11 May 2007 08:50:45 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 May 2007 08:50:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 11 10:50:44 2007 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.50) id 1HmQpn-0007x9-1n for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 10:50:43 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmQxB-00063x-I2 for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 04:58:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmQx5-00063r-WD for emacs-devel@gnu.org; Fri, 11 May 2007 04:58:16 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmQx0-0005zE-B0 for emacs-devel@gnu.org; Fri, 11 May 2007 04:58:14 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmQx0-0005yp-2Z for emacs-devel@gnu.org; Fri, 11 May 2007 04:58:10 -0400 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HmQpa-0003xB-Ff for emacs-devel@gnu.org; Fri, 11 May 2007 04:50:30 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-84-228-164-100.inter.net.il [84.228.164.100]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id COF62136 (AUTH halo1); Fri, 11 May 2007 11:50:27 +0300 (IDT) In-reply-to: <876470ekuz.fsf@red-bean.com> (message from Karl Fogel on Thu, 10 May 2007 08:53:08 -0700) X-detected-kernel: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) 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:70792 Archived-At: > Cc: storm@cua.dk (Kim F. Storm), eliz@gnu.org, emacs-devel@gnu.org > From: Karl Fogel > Date: Thu, 10 May 2007 08:53:08 -0700 > > Basically, I proposed always having an open trunk (or some place > where new changes can be checked in). We'd use branches: > > a) To isolate release lines from trunk churn. > b) To isolate trunk from large, unstable batches of new code until > that code is ready. Remember my message a day or two ago where I explained that Emacs development needs experts in many different areas to be part of the core team (those who can approve or reject patches)? You agreed with that, I think. If we don't have enough experts, how can we make sure the release branch remains stable? Someone needs to review patches suggested for that branch and make sure they are safe. A single volunteer is not very good in splitting her attention between two potentially very different code bases, so many areas will need two people. And on top of that, volunteers generally like new development much more than maintenance-like activity one finds on release branches. That's the problem in always having an open trunk in Emacs: you need roughly twice as many experts to handle a stable release branch and the trunk at the same time. Right now, we don't even have a single full team, let alone two. The MAINTAINERS file was born out of the last similar discussion we had; it was supposed to become a starting point for bringing people on board who would volunteer to become our experts for specific areas. You can take a look at it: since its introduction in November 2001, it got exactly 4 non-trivial changes, and an alarming amount of core files and packages still have no responsible expert associated with them. Given this situation, it's IMO a miracle we are able to release a stable version at all. If you ask me, I won't even consider going to the scheme you suggest until the list of files in MAINTAINERS for which there's no responsible individual is significantly reduced. > I've seen it work very well on other projects. Please name the largest project where it works very well, and let's compare its size and the number of disjoint areas of expertise it requires to those of Emacs.