From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Robert Anderson Newsgroups: gmane.emacs.devel Subject: Re: [Fwd: [arch-users] Re: Gud lord!] Date: 07 Jun 2003 22:01:29 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1055048489.30724.282.camel@lan1> References: <1055034587.1439.121.camel@lan1> <87el256zha.fsf@wesley.springies.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1055047885 27530 80.91.224.249 (8 Jun 2003 04:51:25 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 8 Jun 2003 04:51:25 +0000 (UTC) Cc: emacs Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Jun 08 06:51:24 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19Os9M-00079u-00 for ; Sun, 08 Jun 2003 06:51:24 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19OsSi-00019E-00 for ; Sun, 08 Jun 2003 07:11:24 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OsBX-0002y3-7g for emacs-devel@quimby.gnus.org; Sun, 08 Jun 2003 00:53:39 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19OsBE-0002iu-NM for emacs-devel@gnu.org; Sun, 08 Jun 2003 00:53:20 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19OsAy-0002AH-HX for emacs-devel@gnu.org; Sun, 08 Jun 2003 00:53:05 -0400 Original-Received: from pimout3-ext.prodigy.net ([207.115.63.102]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19OsAw-00027L-Po for emacs-devel@gnu.org; Sun, 08 Jun 2003 00:53:02 -0400 Original-Received: from [192.168.0.2] (adsl-64-163-139-137.dsl.snfc21.pacbell.net [64.163.139.137])h584r0WG075130; Sun, 8 Jun 2003 00:53:01 -0400 Original-To: Alan Shutko In-Reply-To: <87el256zha.fsf@wesley.springies.com> X-Mailer: Ximian Evolution 1.0.8 (1.0.8-11) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:14909 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14909 On Sat, 2003-06-07 at 20:05, Alan Shutko wrote: > Robert Anderson writes: > > > They are defined by regexps. I don't think regexps can reasonably be > > considered "murky." > > Some people, when confronted with a problem, think "I know, I'll use > regular expressions." Now they have two problems. > - Jamie Zawinski[1] I believe that's "borrowed" from the original quote about awk, which I'm not sufficiently motivated to look up. If regexps are somehow unacceptable, then I think emacs has deeper problems than arch does. If people really really need, say, shell globs instead, that could be added in a few lines of code. > > I don't see how you can say that it is not stable. The core of the > > system has been stable for a long time. I don't see how performance > > improvements can be considered "instability." > > Any changes the system go through will have to be tracked by someone. > If the existing CVS crew were to admin arch as well, they'd be even > more overworked. There isn't really an "admin" for arch the way there is for CVS, because it is not a centralized system. Otherwise, Emacs developers would have to learn > everything about arch, at the cost of doing Emacs development. Well sure, but by that argument no developer would learn any tool, including emacs, because it would take time away from doing something else. That would of course not be an advisable path to maximal productivity, IMO. (And > it would be nice to get a release out sometime.) This change will > also impact all of the Emacs developers, taking time away from any of > their development. If I was going to propose a migration, which I'm not, I would propose it in a way that would make such a statement patently false. > Any time the software needs to get upgraded, or file formats get > changed, or the user-defined naming conventions turn out to be > ill-advised and need to be changed, productivity on all levels will > be hurt. Of course such things have to be weighed against what you get out of the trouble. > > The only thing that needs to be worked out about those other things > > is users' understanding of them. > > Sure... and that takes time and effort that could be spent stabilizing > Emacs so that a release with new features can get out. Perhaps if emacs was using arch it would have 2x the contributors, since contributions could be done without requiring CVS write access to begin or work on significant contributions, and releases would get out faster than before. The amount of evidence for your assertions about lost productivity are comparable to mine about increased productivity. > And since arch is immature, it means that all the best practices have > yet to be figured out. The lowest hanging fruit in "best practices" for revctl has been well-known for ages. You'd like to be able to rename files. You'd like to be able branch conveniently and merge those branches conveniently. You can get that stuff right away with no experimentation. > Why force that on Emacs developers? Where have I forced anything on anybody? I'm simply stating some facts interspersed with some opinions about revctl. > No matter how mature arch is, or how well-documented the transition > steps may be (like importing the multiple active branches currently > under development in a sane way) it would still take work and cause a > bunch of disruption. And for the ability to rename files[2] it's > certainly not worth it. Agree. > For the rest of the features, it may be > worth it... or maybe svn would be better[3], or maybe something > else. But that decision can wait. Wait for what, I wonder? > [3] which _does_ offer a CVS->SVN conversion tool.... Such notions of "archive conversion" are deeply ill-conceived, IMO. I see no compelling reason to "fake" development history and many reasons not to. Bob