Re: Release process

On Aug 1, 2006, at 9:55 PM, Paul Guyot wrote:

> Le 2 août 06 à 11:48, Landon Fuller a écrit :
>
>> If the release process isn't ferreting out bugs, or is not agile  
>> enough to incorporate fixes quickly enough, do you have a  
>> suggestion for improving the situation?
>> Telling users to switch to CVS for the latest changes negates the  
>> purpose of doing releases at all, which was to shield users from  
>> unstable code in HEAD.
>
> The recent fiascos of releases 1.3 and 1.3.1 show indeed that there  
> is something wrong with the release process.
> But it is not (only) a matter of the timing of release. It's mostly  
> a matter of testing.

I think calling both those releases a "fiasco" is a bit of an  
overstatement.

1.3, due to the fetch bug, was definitely flawed. I think we'd all  
agree that it was pushed out the door without sufficient testing.  
That bug, for instance, was introduced in code just days old at the  
time of the release.

1.3.1 was a response to 1.3, and was pushed out pretty rapidly to  
correct that bug, but is nonetheless quite usable. We've had several  
reports of problems building that release, but I suspect the number  
of such cases is quite limited.

Rather than doom and gloom, I must say that I'm just pleased to see  
the progress we've made, and that there is progress. I suspect we'll  
release 1.3.2 fairly soon, and I hope we can keep up the trend of  
smaller, lighter weight, releases as needed.

As for the release process, I'd like to point out several things:

  - First of all, the release process document was written (by me)  
mostly as a crib sheet to remembering the steps needed to put out a  
release. It is not set in stone by any means. I see it more of a "how  
to" than a "must do", though some of it, such as proper tagging, are  
important practice.

  - There is no requirement in the "release process" for release  
candidates. I believe release candidates are useful especially if  
there are concerns about whether a build is actually good (i.e., did  
the release process generate a usable image). As others have pointed  
out, rc's are of little value, otherwise, if they get no testing.

  - With selfupdate, we have the opportunity to quickly and easily  
put out quick changes based on little else than generating a cvs tag.  
We don't necessarily have to even spin tarballs or disk images. I  
would suggest that we might try for this for a quick 1.3.2 release,  
for instance: just tag 1.3.2 on the 1.3 branch, and release it via  
the RELEASE_TAG mechanism. I think doing this strikes a good balance  
between effort, stability, and responsiveness.

The key thing in any release is to judge the magnitude of the changes  
that have gone into it, the risk they bring, and the testing they  
have received in deciding how much time, formality and further  
testing is required to release the code.

James