From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: when emacs 22.1 release will ready? Date: Mon, 30 Apr 2007 12:15:46 +0200 Message-ID: References: <259495020704291337s35dd584fi3b7ef1dd511b11d4@mail.gmail.com> <4635B7F9.8090909@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1177928219 9102 80.91.229.12 (30 Apr 2007 10:16:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 30 Apr 2007 10:16:59 +0000 (UTC) Cc: lennart.borgman@gmail.com To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 30 12:16:57 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 1HiSwB-0007OO-9H for ged-emacs-devel@m.gmane.org; Mon, 30 Apr 2007 12:16:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HiT2L-0002Op-F4 for ged-emacs-devel@m.gmane.org; Mon, 30 Apr 2007 06:23:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HiT2G-0002L2-O8 for emacs-devel@gnu.org; Mon, 30 Apr 2007 06:23:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HiT2E-0002Jk-RY for emacs-devel@gnu.org; Mon, 30 Apr 2007 06:23:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HiT2E-0002Jh-HL for emacs-devel@gnu.org; Mon, 30 Apr 2007 06:23:10 -0400 Original-Received: from mxfep03.bredband.com ([195.54.107.76]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HiSw3-0001vC-3M for emacs-devel@gnu.org; Mon, 30 Apr 2007 06:16:47 -0400 Original-Received: from ironport.bredband.com ([195.54.107.82] [195.54.107.82]) by mxfep03.bredband.com with ESMTP id <20070430101645.NYMQ23113.mxfep03.bredband.com@ironport.bredband.com> for ; Mon, 30 Apr 2007 12:16:45 +0200 Original-Received: from ua-83-227-131-3.cust.bredbandsbolaget.se (HELO kurono.home) ([83.227.131.3]) by ironport.bredband.com with ESMTP; 30 Apr 2007 12:15:48 +0200 In-Reply-To: <4635B7F9.8090909@gmail.com> (Lennart Borgman's message of "Mon\, 30 Apr 2007 11\:33\:45 +0200") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) X-detected-kernel: Solaris 8 (1) 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:70402 Archived-At: "Lennart Borgman (gmail)" writes: >> With a similar release procedure for Emacs, Emacs 22.1 had been >> released in 2004, and 23.4 would be ready for release next month. > > What do they do to keep control over the quality? I guess they are > using a lot of unit testing for the kernel, or? > > Is that something that could be done for Emacs? I would propose that > this should be done, in a proper manner. The way I would like to see > it done is to add unit tests when relevant. There are a few points to > watch out for: > > - Any change. > - Any bug reports. > - Any code that is hard to understand. > > A problem is of course that Emacs is screen oriented and that it is > much harder to have an automatic testing framework for that. I do not > know how people do that now, but semi-automatic result testing should > be possible in cases for fully automatic testing is not possible. I wrote some simple unit-test for CEDET (http://www.emacswiki.org/cgi-bin/wiki/CollectionOfEmacsDevelopmentEnvironmentTools) Having done so, I think emacs is fairly well suited for unit-tesing. This is because, unlike many gui applications, things dont move around very randomly in an emacs buffer. You can set-up a buffer to, for instance, test font-locking. At a given character position you will expect to find a certain property, if it works. You have also the possibility to create macros, which re-create a certain test environment, fairly conveniently with inbuilt emacs facilities. The problem is of course to get developers interested in creating unit-test. Another useful method is getting bug-reporters to supply unit tests for their bugs. If some unit-testing frameworks, like http://www.emacswiki.org/cgi-bin/wiki/UnitTesting, where included in emacs, maybe the bug-reporting template in emacs could suggest writing a unit test for the bug when reporting it. > Of course, this is work and it takes time. But if the impression that > changes create regression is valid then I think something like the > above is a possible way to get out of it and get shorter release > cycles. -- Joakim Verona