From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: MAINTAINERS file Date: Fri, 07 Mar 2008 19:06:27 -0800 Message-ID: <47D202B3.8020503@emf.net> References: <18375.18663.981150.252393@kahikatea.snap.net.nz> <85hcfi28n2.fsf@lola.goethe.zz> <47D18DBF.5020302@emf.net> <47D1F997.6030303@emf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1204939728 4043 80.91.229.12 (8 Mar 2008 01:28:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Mar 2008 01:28:48 +0000 (UTC) Cc: eliz@gnu.org, rms@gnu.org, jeremy@jeremyms.com, emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 08 02:29:15 2008 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 1JXns9-0008VQ-84 for ged-emacs-devel@m.gmane.org; Sat, 08 Mar 2008 02:29:13 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXnrb-0002gP-Fw for ged-emacs-devel@m.gmane.org; Fri, 07 Mar 2008 20:28:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXnrX-0002fU-LM for emacs-devel@gnu.org; Fri, 07 Mar 2008 20:28:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXnrV-0002eA-VO for emacs-devel@gnu.org; Fri, 07 Mar 2008 20:28:35 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXnrV-0002e4-SS for emacs-devel@gnu.org; Fri, 07 Mar 2008 20:28:33 -0500 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JXnrK-0002ej-SD; Fri, 07 Mar 2008 20:28:23 -0500 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 24833402; Fri, 07 Mar 2008 17:28:18 -0800 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:91686 Archived-At: So, one or both of us should probably get rightly flamed soon for being too off-topic or not trimming CC's or something but I'll risk at least one more round: Juanma Barranquero wrote: > I don't think Richard's policies are crazy; I respect him and his > accomplishments. But I'm don't think either that what I'm suggesting > is a radical change in policy, unless "stop and look at the > alternatives" is considered radical. > > As a kibbitz I agree with you. I'd even put it more strongly. And this will also illustrate how I basically agree with ESR's sentiment about version control even if I disagree with many details of where he took it: The GNU project as amassed an enormous treasure of software tools: all of the programs dubbed "GNU". Legal ownership of copyrights is all over the map but in some tangible way you could say that "GNU just *has* all of these software 'assets'." Most of those tools, by the way, are moving targets: development continues on them with or without a GNU project per-se. So, this is a very "virtual" collection of software that comprises GNU. It's a big bag of projects-that-share-mutual-good-will as much as its any particular big bag of source code bits. GNU has historically been good at growing its treasure of software tools, but historically very poor at organize those into larger systems. Other people, other groups, with agendas that are different from the the free software movement's have taken over that function: Parties outside of GNU organize collections like this into "complete systems" but GNU itself has failed to do so. Well, it doesn't take "rocket science" to organize lots of tool projects into a "complete system" project but it does take a lot of coordination, record keeping, archival, etc. There's a huge *information management problem* to solve and that problem is about organizing the output of all of the individual, moving-target, software-tools free software source code projects. Another way to say it is that, to really start thinking about building a complete system, GNU has to find a way to turn the list of GNU programs into a kind of living archive of those source code resources. With things nicely organized, then a lot of the tedious work of assembling complete distros can begin to be systematized. The alternative to that kind of "bureaucratization" looks like Debian: throw people at the problem. Debian works on the integration problem by doubling up, roughly, on the number of project maintainers so that every project has a shadow maintainer in Debian who does the pavement-hitting foot work of gathering up source and moving into the Debian collection. The Debian-like alternative is *incredibly expensive* if we are counting up *labor*. It is (relative to most projects) a *huge* effort. There has to be a more efficient approach. GNU *could* contemplate the dvcs problem from *that* angle: trying to find ways to encourage the individual projects to make tool choices that make complete systems much less expensive to assemble. That, in my opinion, would be a good investment strategy (though a challenging mess of tactical problems). A dcvs choice is important from that very broad perspective: thinking about it as a choice that governs the "inventory system" for the GNU project's source code. It's hard, though, to make that case. There's not a lot of point to making up strategies for organizing all the source of a complete distro unless it's realistic that there will be resources to follow up on that strategizing. There seem not to be such resources so, there's a sharp limit on the value of strategic thinking for GNU. -t