Re: [PHP-DEV] php 4.1 From: Hartmut Holzgraefe (hartmut <email protected>)
Date: 11/15/00

André Langhorst wrote:
> we're not living in an optimal world, I guess this would fail - how do
> developers reveal bugs?
> a) they're using their extension for some dedicated purpose and all bugs
> will be revealed using it in a very special case and thus fixed to
> enable using it further, personally
> b) bugs will be revealed by users who're *using* these extensions on
> completely different environments and in a different manner, as far as a
> feature is present (if buggy or not) people try to use it
yes, but in addition to this a extension developer has only to options
to make his extension public (unless we get extensions seperated from
the core in CVS and release distributions):
either developing it in silence and pushing it into the main branch
when he or she thinks it is 'good enough' or putting it in early,
which gives a lot of additional peer review but also introduces
'unready' code into the main branch and possibly into releases

 
> how do you decide that a feature has "grown up"?
"grown up" shouldn't mean perfect, but we have a lot of extensions and
functions right now that simply do not work (and are known not to)
(the complete ext/dav, imap_compose() ... just to name a few)
and we have distributet them with every 4.0.x release ....

> Offer downloading 2
> verions, one marked "stable" the other marked "development"? how do you
> ensure that people are trying their apps with "development" versions and
> not switching from "stable" to "stable" and problems show up then?
as with every other projects that follows this scheme you have some
'early adaptors' that use it for the new features or just for the taste
of it
i know of projects that used PHP 4 back to 4.0beta4 even in production
environments because the features-to-problems tradeoff was positive for
them
others are more conservative and will not switch before they have the
feeling that a new release is really stable for them
with the current scheme theese are the ones that always stay some
versions behind and only do updates when they really have to,
mostly due to security reasons
theese users would benefit from a more conservative stable branch
which is still maintained regarding bugs and security issues but
that doesn't come up with new supprises (aka. features, working or not)
with every minor release step

> sure, I'd consider "asymmetric encryption" and "compressed output" not
> being stable, but when is the date I do?
whenever the 'makers' think it is and nobody else objects to it ...

 
> just to name such an issue regarding the CORE language: I thought
> returing variables by references originating from methods is supported
> and ought to work, because it worked for me all the time and nothing
> negative is said in the documentation (you could argue that it isn't
> documented at all, what would criticize the documentation ([1] either it
> should tell us not to do this or [2] it should tell us that it's
> possible in unawareness of possible failures)
> now zeev told me that it never should have worked properly at all, thus
> PHP has been UNSTABLE for many months
(Zeev has already answered most of it ...)

 
> Most people spending their free time on extensions don't have the
> ressources to do some scientific regression testing, thus regarding
> *functions* you cannot decide whether a version is stable or not (except
> common ones, eg. mysql)
on the other hand it is almost impossible to get a new feature or
extension from zero to usable/stable between two minor release steps

> regarding functions it should be possible writing a regression test
> suite covering all basic functions and core language constructs in most
> widespread usage (regtests have been resurrected but I don't know if
> such tests are included)
this should be done no matter how a developement branch is classified,
but a developement branch should be allowed to fail from time to time
while the stable branch should be required to pass whatever tests we
have available (regression, QA-team)
 

> I personlly dislike the linux kernel numbering, preferring mysql
> versioning (version numbers for features, gamma,beta,alpha sufix for
> stability) - in addition you can download the last 6 (maybe 7) versions
> if a specific version does not work for you
i don't care much about how we name it if we do it,
but the kernel numbering scheme should be well known by now
(isn't PERL going to use it, too ...?)

 
> It would be nice if everyone takes part in this discussion to force
> things like experimental branches,

> PEAR improvement to cover C and PHP-class extensions,

> bug-QA (means forcing devs to close specific serious bugs)
that's what the 'feature freeze' and 'code freeze' phases
in the transition from 'developement' to 'stable' should
be used for (although it didn't seem to work for kernel 2.4 :(

the 'freeze' phases will continue until their goals are
reached and no public developement takes place durign this
time and even for some short period after release so that
developers should get focused on reaching the goals for
theese phases asap so that they can get back to new
developements and experiments on a new developement branch

> or to reject these as methods that do not belong to the
> PHP spirit (development)

> regarding QAT (building+testing+bugs) I think there's some progress
> recognizable and that it'll end up positively
giving the QA volunteers a less moving target should ease their job
a bit

 
> sporadically there are some nice discussions but I yet have to see the
> effects, perhaps someone with widespread php activities and
> knowledge should take care of these things as a "designated coordinator"
> with responsibility or whatever to ensure that "commercial frustration"
> (citing Thomas) and user frustration are foreign words in PHP
i don't think that we would be able to agree on a single "designated
coordinator", but i would like to see some sort of "design advisor"
or at least a more relibale 'request for comments' mechanism

i have been asking for comments on feature ideas every now and then
in the past, but even if i included patches (before commiting to CVS)
or asked twice the only way to get real feedback before you put
something
into the CVS is to declare that you are not asking again and that you
will take no comments as a 'yes' 

--
Hartmut Holzgraefe  hartmut <email protected>  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>