From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29214 invoked from network); 10 May 2001 11:34:39 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 May 2001 11:34:39 -0000 Received: (qmail 18808 invoked by alias); 10 May 2001 11:34:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14297 Received: (qmail 18784 invoked from network); 10 May 2001 11:34:30 -0000 Message-ID: To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: Release process In-Reply-To: Your message of "Thu, 10 May 2001 04:03:56 PDT." <20010510110356.76912.qmail@web10403.mail.yahoo.com> Date: Thu, 10 May 2001 12:33:56 +0100 From: Peter Stephenson Felix wrote: > Quiet time to me would be heavy restrictions on what can get checked in. I'd > suggest things like no C code changes, unless they fix a crashing or > other very > serious bug. And these should be small changes. Changes that are more than > a couple lines should be reviewed. This tends to be where the problems start. Things that destabilise releases in the past have tended to be fixes for serious bugs, such as not even compiling on some well-known target. In practice that means simply deciding patch by patch. We've been (supposedly) scaling down development for some time. > Very limited script changes. It wouldn't be > ok to change core scripts; _path_files, for instance, since that is so > heavily > used. Though it might be ok to add a new completion function for a command > that isn't currently covered, though even that would be iffy. It would be ok > (even encouraged) to add new tests and new test cases. Also, fixing, adding, > clarifying documentation might be ok (as long as we check it afterwards.) This is all sensible. > I would say we need at least two weeks time after we announce on > zsh-users th at there is a pre-release available. That's fine. It's been almost a year since the last full release anyway, and goodness knows how long since the first 3.0. > During the quiet time, I think it would be useful to add new tests. In particular tests for options and builtins are missing. > Also, I > think it would be useful to run various development tools (profiling, code > coverage, memory leak, benchmarking etc.) against zsh to find the problems we > can't easily see. It would be great if people volunteered to do those tasks. This just means anybody who has such tools running them. This is always encouraged. -- Peter Stephenson Software Engineer CSR Ltd., Unit 300, Science Park, Milton Road, Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************