Re: [PHP-DEV] Re: [PHP4BETA] PHP 4.0.0 Release packaged

Hello Zeev,

On 20-May-00 20:48:42, you wrote:

>> >> Does that mean that http://bugs.php.net/version4/bugs.php
>> >> isn't uptodate? The page lists 488 open bugs.
>>
>> >No software release is bug-free, unfortunately. :)
>>
>>That's Microsoft's line of thinking.  However, Microsoft is money driven
>>and their market can't wait.  What's the rush here with PHP 4?
>>
>>Last time I looked there were plenty of reproduceable bugs and if somebody
>>reported them is because they are affecting at least who reported them.

>Unfortunately, Microsoft's line of thinking isn't like that because it's 
>money driven.  Not alone, anyway.

No? It's all about market. Marketeers push release dates no matter what.
The difference is that Microsoft makes more money releasing products
earlier.


>Not a single large-scale piece of software in the world, open or closed 
>source, is bug free.  All software packages include both reproducible and 
>non reproducible bugs.  I don't think that even the biggest Linux 
>enthusiast would claim that any given Linux kernel in history was/is bug 
>free.  Nonetheless, there have been at least a couple of hundred releases 
>of Linux kernels, from which at least a few dozens were tagged 'Release'.

>Finally, there's also something that people fail to understand is that PHP 
>4.0.0 is being waited for by thousands, if not more, who are waiting to 
>upgrade.  Some of them rely on their providers' web software, who refuse to 
>install PHP 4.0 until it's tagged Release.  Others have a mythical belief 
>that the word 'Release' next to a software version means it's bug-free.  It 
>doesn't mean that, never.

>We feel that the core of PHP 4.0 is stable, at least as stable as PHP 
>3.0's, and there's no reason to delay the move to it.  We'll sort out bugs 
>as quickly as we can, independently of the 'Release' tag.  After 4.0.0, 
>there'll be 4.0.1, 4.0.2, and probably quite a few more revisions afterwards.

Completely agreed, but I have a hard time to understand these sudden
release rushes.

If you care for some intentionally constructive criticism, from where I am
standing it seems PHP developments as many other Open Source projects lack
of a more professional software development approach.  This rules against
the quest of Open Source projects that are trying to get credibility in
real the world where people with fewer arguments prefer paid software
(supported?!?) to free software.

I am not saying that the current developers are not competent, it's quite
the opposite, but if you care to improve PHP credibility, please read up to
the end:

- While thinking about this issue I came to the conclusion seems that PHP
releases have no target date to begin with or at least a target date to
keep in mind, but then all the sudden come these messages:  let's
release Monday!  Why Monday?  Why not, let's release when all reproducible
bugs get fixed?

The way it is said, it seems as it will be released Monday no matter what
and if it builds OK on many platforms it is just fine regardless of any
outstanding bugs that prevent people from using it.

- Release candidate versions are misleading.  The way I understand it,
the first release candidate version means code freeze, i.e., no more new
features.  PHP Release Candidates just means, I wish it could be released
soon, but people keep on adding new features.  New features mean new bugs.
New bugs mean more release candidates or buggier final release.

There should be some discipline, but PHP development completely lacks it on
this aspect.  Just go to the NEWS or ChangeLog files and see how many new
features and new fixes were done after Release Candidate 1.

- Bug fixing is mood based.  If developers do not like the face of the bug
reports or the reporter they just skip it, probably for a long time.  Then
when all the sudden somebody decides to make a release real soon and
announce an initiative to close as many reports as possible.

Many bugs will be left in the bug database for a long time when it's not
forever.  I know that fixing bugs is a drag, but if somebody reports them,
it is because they are affecting at least the reporters.  If they are not
addressed any time soon that discourages people from reporting bugs and
people may even downgrade to more stable versions.

Bugs should be fixed in a "first come, first addressed" basis and if
possible before adding new features or making new releases.  At least the
reproducible bugs should have that kind or priority. Bugs should not be
addresses based on sympathy with the report or reporter.  That's an
unreliable way of dealing with users. If that is as good as it gets, you
can not blame users with money from preferring paid software (supported?!),
regardless if the commercial competing products are not as capable as
your free software.

- Final releases are done and many new features are not documented.  What
is the point of announcing cool features like Shockwave Flash support but
users can not find any documentation to use it? This makes the developers
look like hackers or just amateurs.

Developers should be obligated to enter documentation for the functions
that add or else they might never be documented at all.  You may claim that
developers do not have the time both add code and document their new
functions, but I have seen developers that keep adding multiple features and
not documenting any.  If you do not have time to document one feature that
you add, you certainly will not have time to add other features.

I know that documenting software is a real drag, but the lack of proper
documentation is a big disadvantage of many free software projects that
plays against its credibility.  I know that PHP is not the worse documented
free software project, but the reality is that many developers rather have
to pay for less capable software that is properly documented than using
free software that you have to guess how to use it by browsing the source
code.


So, to sum up:  PHP releases need to go through an effective code freeze
period and from then on only bug fixes are performed until there a release
is produced.  All reports should be handled in a first come, first
addressed basis.  Reproducible bugs should have the priority.  All features
should be properly documented or else you would better not announce them.

I think that these rushed releases should be rethought.  PHP needs all the
credibility as it may get. Rushing it as it is, is not helping.


I hope you take these criticisms as being constructive.  I would not bother
to type a 6KB message with criticisms if would not hope for the best to
PHP.  I believe that it is a good thing that somebody bothers to put the
finger in the wound to make you see what needs to be healed.  I hope this
hopes healing some of the wounds.


Regards,
Manuel Lemos

Web Programming Components using PHP Classes.
Look at: http://phpclasses.UpperDesign.com/[email protected]
--
E-mail: [email protected]
URL: http://www.mlemos.e-na.net/
PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp
--