From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28998 invoked from network); 10 May 2001 11:04:07 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 May 2001 11:04:07 -0000 Received: (qmail 784 invoked by alias); 10 May 2001 11:04:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 14296 Received: (qmail 766 invoked from network); 10 May 2001 11:04:00 -0000 Message-ID: <20010510110356.76912.qmail@web10403.mail.yahoo.com> Date: Thu, 10 May 2001 04:03:56 -0700 (PDT) From: Felix Rosencrantz Subject: Release process To: zsh-workers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii It's not clear to me what our release process is. For example, I don't know what criteria we are using for saying that the release is ready. I think we need to be a little more formal in general, but particularly for this first 4.0.X release. The first 4.0.X release is much more significant than the 3.1.X development releases. Also, there are some fantastic changes since 3.0.X that will motivate people to 4.0.X zsh. (Maybe even distributions like RedHat will become current.) Our pre-release announcements end up being calls to start making changes. I know I tend to get caught up in this frenzy of wanting to check in last minute changes. However, many of these changes have the potential for destabilizing the code (introducing bugs, uncovering old bugs, etc.) I think we need a longer period of quiet time in the codeline. 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. 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.) I would say we need at least two weeks time after we announce on zsh-users that there is a pre-release available. My personal experience has been that it can take up to a week for me to pull a pre-release and get it all built and used. (Because I need to find time, or there is some sort of machine problems, etc.) And then it takes some time using it in my environment before I cover all the different ways I use my shell. I think we have a great start on tests, but they are not very through yet. So having our users bang on it for a little while should help uncover problems. I know the people on this list are using the latest version everyday, though I think it is helpful to have fresh users, who are likely to find new ways to break the shell. I think we need more than a just a few days after the zsh-users announcement. During the quiet time, I think it would be useful to add new tests. 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. Just some thoughts/concerns on our release process. -FR __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/