Release process

Release process

[Felix Rosencrantz]

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/

Re: Release process

[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 <pws@csr.com>                  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.
**********************************************************************

Re: Release process

[Bart Schaefer]

On May 10,  4:03am, Felix Rosencrantz wrote:
} Subject: Release process
}
} 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.

This would be another reason to use a CVS branch.  Put the release code
on the branch; let people continue committing whatever they happen to be
working on, on the trunk; if it turns out to be a critical bug fix and
does not destabilize anything, selectively merge it to the branch.

On May 10, 12:33pm, Peter Stephenson wrote:
} Subject: Re: Release process
}
} 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.

It'll be 5 years in August (June if you count pre-releases).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Release process

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Thu, May 10, 2001 at 05:08:45PM +0000,
Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
^^^^^^^^^^^^^

[...]
> On May 10, 12:33pm, Peter Stephenson wrote:
> } Subject: Re: Release process
> }
> } 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.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> It'll be 5 years in August (June if you count pre-releases).

Allright.
Now Bart has won the "who is the _real_ zsh goodness" contest :-)

Ciao,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]