Software Release Management is a Thankless Task

Software release management is a time consuming, thankless task.  The release manager must balance the need for stability against the desire for every bug to be fixed and for great new features to be made available.  Not all developers (or feature users) have the same idea of the goals of a release.  The current PHP 5.2 release manager, Ilia Alshanetsky, has got each PHP release he's looked after into good shape. And luckily he's coped with any flak he's got.

Big software projects have well defined feature scope.  They can enforce rules like "no feature checkins until you have fewer than X bugs".  Or "no checkins unless your code test coverage number is greater than Y%".  The responsibilities of feature area owners are clear and communication is constant.

It is harder to be so strict with PHP development.  The open source community needs to keep its mostly volunteer developers enthused and appreciated.  With its relatively fast pace of development there are constant small changes to the code base.  This means there is a huge gray area about what is a bug versus a feature and about the priority of each change.  It is harder to force tests or documentation to be created with each checkin.

Like with many things, developers always seems to leave things to that last minute.  Ilia cleverly uses the announcement of the first release candidate (RC) as a wakeup call for all the last-minute features to get hurried up.  However to me this means they don't get a full release cycle of testing, which is not ideal.

I'd like to see just a teency-weency bit more rigor in PHP releases. I don't want to see massive overheads of process and paperwork but just some tweaks (to start with).  I'd like to see a well announced (possibly fixed, e.g. 1st day of every third month) date for the first RC of the next upcoming release.  Yes, the date may change if planned big features slip but the new target can be published.  When the first RC happens I'd like to see a lockdown of the code base enforced.  Only fixes for logged bugs should be allowed to be merged and the release manager should pre-approve all code changes, taking decisions in that gray area of what is and isn't important.

We should also make better use of Lukas's release planning wiki or www.php.net to do scheduling.

I see these suggestions as reducing the confusion about the release process, minimizing (unintentional) bias about certain features or developers, and helping to improve the testing of features.

Hey, if your code change doesn't get in this release, there is always another one just around the corner.


Comments:

For a while Ilia posted exact dates for planned RC's and stable releases. ATM its more like "at the end of April" kind of dates and I have not been following closely enough in making sure these tentative dates at least make it on the wiki. Also I still think the wiki should be on php.net .. but thats another story :)

Posted by Lukas on April 19, 2007 at 01:46 AM PDT #

It would be good to centralize the information in one place. Regardless whether there is a tightly scheduled RC1 date, PHP developers need to take responsibility to merge new features near the start of a release cycle.

Posted by Christopher Jones on April 19, 2007 at 10:13 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Tourists looking out over an Opal mine
I'm a Product Manager in Server Technologies, working on scripting languages and developer-access.
Email: christopher.jones@oracle.com
Twitter: http://twitter.com/ghrd
Book: Free PHP Oracle book
Download: PHP Linux RPMs with the OCI8 extension
Links: OTN PHP Developer Center

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today