Justin Erenkrantz wrote:
>On Sun, Nov 11, 2001 at 01:04:44AM -0000, [EMAIL PROTECTED] wrote:
>
>> +
>> + * Source code should follow style guidelines.
>> + This can't wait until we have a 2.0-gold release because then
>> + style corrections will conflict with bug fixes found after
>> + release which is not nice.
>>
>
>Personally, I think this is a release showstopper, but I can be talked
>out of that. I don't want to end up in the situation where we go GA
>and then do style changes and then the diffs AFTER the GA become
>cluttered with style fixes. So, I think this needs to happen before
>we go GA. For now, it lands in release-showstopper category.
>
>It also may be best to devise a plan of attack for getting files
>converted to the right style. -- justin
>
Can you quantify the value of doing style cleanups before GA?
I.e., what's the value to the customers (the people who'll use
2.0) of holding up the release in order to fix up the coding style?
I might just be overreacting, but I'm particularly worried about
making this a release showstopper because I fear that it could
offset some of the potential benefits of 2.0.
I assert that a big part of the value proposition that 2.0
will offer to users is lower capital cost:
* Compared to 1.3, it should require less hardware to handle
the same volume of traffic.
* Compared to various commercial servers, it should offer
competitive performance, quality, and features without the
licensing fees.
(Both of these points assume that we'll produce a 2.0 GA release
with great performance and quality, but I think we're close to
doing so.)
From this perspective, delaying GA is generally a bad thing.
While we fix the code indentation, potential users may have to
buy more servers to handle traffic growth under 1.3, or buy
more per-host licenses for commercial servers.
While I'm not opposed in principle to doing a code cleanup before
GA, I'd feel much more comfortable if it either:
* didn't delay the release, or
* added some quantifiable, incremental value for users.
--Brian
