Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 In my humble opinion (humility is a virtue), new modules are fine to add
 while in the release process, as long as there's at least one RC after
 them, to ensure they don't mess up the build or anything trivial like
 that.

Oh, messing up the build is a trivial thing?

 It takes 2-3 months between each and every release, and it'd be a
 shame for the new module author to receive wide exposure and feedback for
 his new code.

As the Midgard extension recently showed, a single line in an
extension can break everything else.  And it can easily go
unnoticed, especially if it is not reviewed by experienced
people.

All new modules can gain wide exposure by distributing them
separately.  They don't need to be in our tree, and
they especially don't need to be added during the release
process.  It is not worth the risk.

So few people have asked for the FastCGI module during the
last two years that I doubt that it was necessary to push it
into 4.0.5.

 In my opinion, the CVS rules should be changed to reflect
 that, just to make Jani happy, or we'd stay outlaws in his mind forever :)

The CVS rules are fine as they are.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 13:10 21/3/2001, Sascha Schumann wrote:
  In my humble opinion (humility is a virtue), new modules are fine to add
  while in the release process, as long as there's at least one RC after
  them, to ensure they don't mess up the build or anything trivial like
  that.

 Oh, messing up the build is a trivial thing?

Yes, it is.  Non trivial things are things that are difficult to find, 
which require long and thorough testing, such as changes to core API 
functions or very common modules.  Figuring whether the build works or not 
is trivial.

  It takes 2-3 months between each and every release, and it'd be a
  shame for the new module author to receive wide exposure and feedback for
  his new code.

 As the Midgard extension recently showed, a single line in an
 extension can break everything else.  And it can easily go
 unnoticed, especially if it is not reviewed by experienced
 people.

Easily unnoticed?  I beg to differ.  As soon as someone tried to build it, 
it failed.  That's why it's trivial, and that's why it's relatively safe to 
do it even while RC's are going.  The rule of 'dont break the CVS build' is 
crucial, and should be followed especially with RC's.  But the worst case 
situation of adding a new module is a broken build, which is noticed 
immediately, and thus is not dangerous.

 All new modules can gain wide exposure by distributing them
 separately.  They don't need to be in our tree, and
 they especially don't need to be added during the release
 process.  It is not worth the risk.

The risk is pretty much non existent, as I demonstrated.  Especially with a 
SAPI module, what you say isn't true.

 So few people have asked for the FastCGI module during the
 last two years that I doubt that it was necessary to push it
 into 4.0.5.

Zeus moved its recommendation from using the native ISAPI/Zeus module to 
using FastCGI, because of instability.  So you can expect FastCGI to be 
more popular.

  In my opinion, the CVS rules should be changed to reflect
  that, just to make Jani happy, or we'd stay outlaws in his mind forever :)

 The CVS rules are fine as they are.

Yes, so says you.  But I beg to differ.

Zeev


--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

No disrespect for the config.m4, it's not all that important if it's 
optimized or not :)

At 13:09 21/3/2001, Ben Mansell wrote:
On Tue, 20 Mar 2001, Jani Taskinen wrote:

  On Tue, 20 Mar 2001, Andi Gutmans wrote:
 
  At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote:
  On Tue, 20 Mar 2001, Andi Gutmans wrote:
  
andi  Tue Mar 20 10:13:21 2001 EDT
   
  Added files: (Branch: PHP_4_0_5)
/php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI 
 config.m4
  fastcgi.c php.sym php_fastcgi.h
  Log:
  - MFH
  
  erhm, I thought that during the Release Process no new things were being
  added
  
  The SAPI extension was never used by anyone before so there's no harm in
  adding it (this is not changing/patching existing functionality).
  It does make two changes to two build files but I took a very close 
 look at
  them and it doesn't seem like they can cause us problems.
 
  Still, it's against the rules.. :) And the config.m4 for it
  isn't..hmm..optimized.

Improvements are welcome... I'm no expert in the build system so theres
no surprises that its far from optimized.

Ben


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 Yes, it is.  Non trivial things are things that are difficult to find,
 which require long and thorough testing, such as changes to core API
 functions or very common modules.  Figuring whether the build works or not
 is trivial.

That might be true for a single build.  We support dozens of
platforms and figuring out whether a change breaks something
on one particular platform is not as simple as you obviously
assume.

  As the Midgard extension recently showed, a single line in an
  extension can break everything else.  And it can easily go
  unnoticed, especially if it is not reviewed by experienced
  people.

 Easily unnoticed?  I beg to differ.

Zeev, there is a difference between the terms 'will' and
'can'.  I've used the latter.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 15:50 21/3/2001, Sascha Schumann wrote:
  Yes, it is.  Non trivial things are things that are difficult to find,
  which require long and thorough testing, such as changes to core API
  functions or very common modules.  Figuring whether the build works or not
  is trivial.

 That might be true for a single build.  We support dozens of
 platforms and figuring out whether a change breaks something
 on one particular platform is not as simple as you obviously
 assume.

I don't think that there would be a real life situation in which a new 
module would break a build under one platform, and won't under another 
platform, without you actually using the module.  The author has to be 
exceptionally 'talented' to achieve that.

   As the Midgard extension recently showed, a single line in an
   extension can break everything else.  And it can easily go
   unnoticed, especially if it is not reviewed by experienced
   people.
 
  Easily unnoticed?  I beg to differ.

 Zeev, there is a difference between the terms 'will' and
 'can'.  I've used the latter.

I know, and as I said, I disagree.  I don't think it can go unnoticed in 
the further RC.

Zeev


--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 I don't think that there would be a real life situation in which a new
 module would break a build under one platform, and won't under another
 platform, without you actually using the module.  The author has to be
 exceptionally 'talented' to achieve that.

The config.m4 just has to reach a certain complexity to
become incomprehensible.  I suggest reading ext/gd/config.m4
for starters.

 I know, and as I said, I disagree.  I don't think it can go unnoticed in
 the further RC.

Ah, of course.  Just as newly introduced bugs in the code are
catched by further RCs..

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 16:20 21/3/2001, Sascha Schumann wrote:
  I don't think that there would be a real life situation in which a new
  module would break a build under one platform, and won't under another
  platform, without you actually using the module.  The author has to be
  exceptionally 'talented' to achieve that.

 The config.m4 just has to reach a certain complexity to
 become incomprehensible.  I suggest reading ext/gd/config.m4
 for starters.

As you may know, new scripts don't tend to be born with nuclear simulations 
as their config.m4, as the gd extension grew to have during the years.

  I know, and as I said, I disagree.  I don't think it can go unnoticed in
  the further RC.

 Ah, of course.  Just as newly introduced bugs in the code are
 catched by further RCs..

No, not even similarly.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 As you may know, new scripts don't tend to be born with nuclear simulations
 as their config.m4, as the gd extension grew to have during the years.

"don't tend" does not preclude the existance of such modules
in the future.

Guys, please play by the rules which are laid down in
RELEASE_PROCESS.  Further decreasing the quality of PHP
releases doesn't help anyone and just makes us look bad.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Thies C. Arntzen

On Wed, Mar 21, 2001 at 03:30:58PM +0100, Sascha Schumann wrote:
 
 Guys, please play by the rules which are laid down in
 RELEASE_PROCESS.  Further decreasing the quality of PHP
 releases doesn't help anyone and just makes us look bad.

i fully agree to sascha. plus i see no real reason to include
a new module once we are in "release-process". new modules
are by default not "producition-stable" so why hurry to
include them in a "official-release"? 

the no. 1 (and maybe only goal) for a release should be
stability and well tested functionality IMHO.

tc


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Hartmut Holzgraefe

Sascha Schumann wrote:
 Guys, please play by the rules which are laid down in
 RELEASE_PROCESS.  Further decreasing the quality of PHP
 releases doesn't help anyone and just makes us look bad.
 
yes, that's it, let's play by the rules during a RC cycle or
don't have rules at all

rules for release cycles might be changed between RC cycles,
but should definetly be applied unchanged while in use



-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77 

Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 16:44 21/3/2001, Hartmut Holzgraefe wrote:
Sascha Schumann wrote:
  Guys, please play by the rules which are laid down in
  RELEASE_PROCESS.  Further decreasing the quality of PHP
  releases doesn't help anyone and just makes us look bad.

yes, that's it, let's play by the rules during a RC cycle or
don't have rules at all

rules for release cycles might be changed between RC cycles,
but should definetly be applied unchanged while in use

I definitely don't agree with this definitely.  A good thing about 
opensource projects is that there aren't committees and thick rule books 
that move and act at the speed of a dinosaur.  When it begins to look that 
way, you know you're in the wrong direction.
It doesn't mean that we shouldn't have rules, but I'll never support rules 
such as 'dont debate/change the rules while [ANYTHING]'.  If the rules are 
broken, or there was lacking vision when we authored them, it should be 
fixed on the spot.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 I definitely don't agree with this definitely.  A good thing about
 opensource projects is that there aren't committees and thick rule books
 that move and act at the speed of a dinosaur.  When it begins to look that
 way, you know you're in the wrong direction.

OpenSource does not mean careless committers and bug-riddled
software.  OpenSource software can excel in code quality and
stableness.

Your personal goal seems to differ from that target.  I think
that is a pity.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 The bottom line is that, as I said, the trick in good opensource software
 is taking calculated risks, and mixing agility with quality assurance.  One
 can look through your binary glasses, and then it's either complete lack of
 quality, or complete lack of risks, and one can look with reasonable
 experienced eyes and strive to get to the right mixture.  I, for one, don't
 enjoy looking through these binary glasses.

Then please start explaining what the right mixture is.
Apparently, we have not found the right mixture yet, unless
of course, patchlevel releases are part of that Great Plan.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 17:15 21/3/2001, Sascha Schumann wrote:
  I definitely don't agree with this definitely.  A good thing about
  opensource projects is that there aren't committees and thick rule books
  that move and act at the speed of a dinosaur.  When it begins to look that
  way, you know you're in the wrong direction.

 OpenSource does not mean careless committers and bug-riddled
 software.  OpenSource software can excel in code quality and
 stableness.

 Your personal goal seems to differ from that target.  I think
 that is a pity.

Your argumentative tone is also a pity.

As for the issue at hand, we differ greatly at the amount of importance we 
attribute to considering rules as if they were God-given.  I care about 
PHP's quality a lot, quite before you were even a contributor to the 
project.  I'm not coming to downplay your caring, but I'm not sure what 
makes you think you can downplay mine.

The fact that you see what I say as if opensource software means 
bug-riddled software or careless committers still doesn't mean that's what 
I'm saying, and obviously (as I'm sure you know deep inside), it's 
not.  That's just your binary way of looking at things, which is thankfully 
not shared by most people.  I stand completely behind what I said, but 
obviously not behind your summary of what I said.

The bottom line is that, as I said, the trick in good opensource software 
is taking calculated risks, and mixing agility with quality assurance.  One 
can look through your binary glasses, and then it's either complete lack of 
quality, or complete lack of risks, and one can look with reasonable 
experienced eyes and strive to get to the right mixture.  I, for one, don't 
enjoy looking through these binary glasses.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

In an attempt to fulfill Cynic's request, I'll only say that this whole 
thread began when I suggested that the release-process is modified to 
reflect that adding new modules is allowed.

Zeev

At 18:03 21/3/2001, Sascha Schumann wrote:
  The bottom line is that, as I said, the trick in good opensource software
  is taking calculated risks, and mixing agility with quality assurance.  One
  can look through your binary glasses, and then it's either complete lack of
  quality, or complete lack of risks, and one can look with reasonable
  experienced eyes and strive to get to the right mixture.  I, for one, don't
  enjoy looking through these binary glasses.

 Then please start explaining what the right mixture is.
 Apparently, we have not found the right mixture yet, unless
 of course, patchlevel releases are part of that Great Plan.

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Andi Gutmans

At 05:03 PM 3/21/2001 +0100, Sascha Schumann wrote:
  The bottom line is that, as I said, the trick in good opensource software
  is taking calculated risks, and mixing agility with quality assurance.  One
  can look through your binary glasses, and then it's either complete lack of
  quality, or complete lack of risks, and one can look with reasonable
  experienced eyes and strive to get to the right mixture.  I, for one, don't
  enjoy looking through these binary glasses.

 Then please start explaining what the right mixture is.
 Apparently, we have not found the right mixture yet, unless
 of course, patchlevel releases are part of that Great Plan.

I think most (probably not all) pl's were sparked due to security bugs 
which were found and we took the opportunity to add another couple of 
important fixes. Those kind of pl's would not have been prevented by any 
Great Plan.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 I think most (probably not all) pl's were sparked due to security bugs
 which were found and we took the opportunity to add another couple of
 important fixes. Those kind of pl's would not have been prevented by any
 Great Plan.

If I remember correctly, 4.0.4pl1 was the only release
which also happened to include security-related changes
beside important bug fixes.

Here is a quick summary.

4.0.4pl1, two weeks after 4.0.4
- broken user function calls affects modules like XML and
  Session, broken Apache Config

4.0.3pl1, three days after 4.0.3
- broken Apache Config handling

4.0.1pl2, two days after 4.0.1
- broken error_reporting() and readdir()

4.0b4pl1, one day after 4.0b4
- magic_quotes crash

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Andi Gutmans

A couple of these were buffer overflows IIRC which were security issues.
Remember the group@ emails about those?
Andi

At 07:17 PM 3/21/2001 +0100, Sascha Schumann wrote:
  I think most (probably not all) pl's were sparked due to security bugs
  which were found and we took the opportunity to add another couple of
  important fixes. Those kind of pl's would not have been prevented by any
  Great Plan.

 If I remember correctly, 4.0.4pl1 was the only release
 which also happened to include security-related changes
 beside important bug fixes.

 Here is a quick summary.

 4.0.4pl1, two weeks after 4.0.4
 - broken user function calls affects modules like XML and
   Session, broken Apache Config

 4.0.3pl1, three days after 4.0.3
 - broken Apache Config handling

 4.0.1pl2, two days after 4.0.1
 - broken error_reporting() and readdir()

 4.0b4pl1, one day after 4.0b4
 - magic_quotes crash

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

On Wed, 21 Mar 2001, Andi Gutmans wrote:

 A couple of these were buffer overflows IIRC which were security issues.
 Remember the group@ emails about those?

Fixes against format-string attacks and for file-upload
issues went into 4.0.3.  Or what are you referring to?

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Andi Gutmans

Why do we need to have an interrogation. Relax, it's not such a big deal.

4.0.4pl1  4.0.3pl1 both had security fixes (Apache config handling was a 
security issue).

Anyway, I still don't understand what the big fuss is about. Let's stop 
arguing about this like 4th graders.
By the way, the error_reporting() pl1 in 4.0.1 was due to a bug which was 
in the CVS a long time. It was not a spontaneous bug that was introduced.

Andi

At 07:50 PM 3/21/2001 +0100, Sascha Schumann wrote:
On Wed, 21 Mar 2001, Andi Gutmans wrote:

  A couple of these were buffer overflows IIRC which were security issues.
  Remember the group@ emails about those?

 Fixes against format-string attacks and for file-upload
 issues went into 4.0.3.  Or what are you referring to?

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 20:50 21/3/2001, Sascha Schumann wrote:
On Wed, 21 Mar 2001, Andi Gutmans wrote:

  A couple of these were buffer overflows IIRC which were security issues.
  Remember the group@ emails about those?

 Fixes against format-string attacks and for file-upload
 issues went into 4.0.3.  Or what are you referring to?

The Apache module issue was a security problem.  A fairly major one, too.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Cynic

Hi Andi!

At 19:58 21.3. 2001, Andi Gutmans wrote the following:
-- 
Why do we need to have an interrogation. Relax, it's not such a big deal.

We don't. I hope no one will take my remarks personally. :)

4.0.4pl1  4.0.3pl1 both had security fixes (Apache config handling was a security 
issue).

One might consider all bugs security issues.

By the way, the error_reporting() pl1 in 4.0.1 was due to a bug which was in the CVS 
a long time. It was not a spontaneous bug that was introduced.

Well, how come it wasn't serious enough to make it into 4.0.1,
and two days later it justified a release of pl1? :) I guess 
such a situation was a symptom of a need for a better RC process...
It improved. I understand Sascha's fear the group was backpedalling 
from the position it has achieved. 

I must say I agree with Sascha and the other people who wrote that 
they'd prefer new stuff _not_ added during an RC period. 
Apache group has a pretty different modus operandi more like FreeBSD
with a group of commiters, and if you check [EMAIL PROTECTED], 
you'll see that they're trying to tighten it even more. They tossed 
CVS branches, and it seems like they're going to use code-freeze 
periods. Now, before someone jumps on this, I know PHP isn't Apache,
and there are other projects that do well without freezes, but I 
still think PHP is a bit too liberal in this area.


At 07:50 PM 3/21/2001 +0100, Sascha Schumann wrote:
On Wed, 21 Mar 2001, Andi Gutmans wrote:

 A couple of these were buffer overflows IIRC which were security issues.
 Remember the group@ emails about those?

Fixes against format-string attacks and for file-upload
issues went into 4.0.3.  Or what are you referring to?

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

 The Apache module issue was a security problem.  A fairly major one, too.

Yes, that is why I mentioned 4.0.4pl1 as an exception in an
earlier email.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Sascha Schumann

On Wed, 21 Mar 2001, Andi Gutmans wrote:

 Why do we need to have an interrogation. Relax, it's not such a big deal.

I'm completely relaxed.  I just dislike twisting history.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

But I referred to 4.0.3pl1 :)

At 21:23 21/3/2001, Sascha Schumann wrote:
  The Apache module issue was a security problem.  A fairly major one, too.

 Yes, that is why I mentioned 4.0.4pl1 as an exception in an
 earlier email.

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 21:25 21/3/2001, Sascha Schumann wrote:
On Wed, 21 Mar 2001, Andi Gutmans wrote:

  Why do we need to have an interrogation. Relax, it's not such a big deal.

 I'm completely relaxed.  I just dislike twisting history.

Sascha,

As Cynic said, it's really a good idea to stop the flame wars.  Being 
cynical (nice coincidence) doesn't help, because it draws cynical remarks 
from the other side (as you could see).  Let's just stop.  The argument 
diverted to unrelated issues anyway.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Jason Greene

Though I am still considered new to this group, I thought I would put in my two cents.

Are we considering fastcgi module stable?  We currently release EXPERIMENTAL modules
as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I don't see 
why the 
module itself could not be included in the RC branch. The only piece that really has 
to be checked 
is config.m4, and in this scenario there doesn't appear to be problems(efficient or 
not). As long as
the withval test is valid, and the module is not enabled by default it really 
shouldn't affect php
as a whole. I believe that this is a fine exception to the rule.

However, if fastcgi is being labled stable, then, IMHO, I believe it should wait for 
thorough testing,
and the next freeze.  

I think that Sascha, and Jani have concerns with this being the first domino in a 
series of continually
growing exceptions to the release process. An RP ruleset is one of those things that 
is often considered
 "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed valid points 
about the functionality
 being important and shouldn't wait.  Which, if there is big need for it, why can't 
there be a compromise?

Perhaps everyone should consider altering the RP ruleset, to include an exception 
about adding new 
modules. 

If the exception policy was in place here are some questions of thought:
What would be necessary to make it safe to php in a whole?
What should the requirements be to allow this to happen ( ex. a lot of user demand, 
replaces something considered unstable) ?
Should this require any re-testing?
Should this require x amount of RCs to follow and how many?
Should there be a vote on whether or not to allow the module in?
Is this module something that should first be released as an add-on?

I honestly agree with both positions on this one, and I think  good can come from both 
of them : )

-Jason




- Original Message - 
From: "Zeev Suraski" [EMAIL PROTECTED]
To: "Sascha Schumann" [EMAIL PROTECTED]
Cc: "PHP Developers Mailing List" [EMAIL PROTECTED]; "PHP Quality Assurance Team 
Mailing List" [EMAIL PROTECTED]
Sent: Wednesday, March 21, 2001 1:33 PM
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) 
/sapi/fastcgi


 But I referred to 4.0.3pl1 :)
 
 At 21:23 21/3/2001, Sascha Schumann wrote:
   The Apache module issue was a security problem.  A fairly major one, too.
 
  Yes, that is why I mentioned 4.0.4pl1 as an exception in an
  earlier email.
 
  - Sascha Experience IRCG
http://schumann.cx/http://schumann.cx/ircg
 
 --
 Zeev Suraski [EMAIL PROTECTED]
 CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/
 
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]
 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

It's definitely considered experimental.

Zeev

At 22:19 21/3/2001, Jason Greene wrote:
Though I am still considered new to this group, I thought I would put in 
my two cents.

Are we considering fastcgi module stable?  We currently release 
EXPERIMENTAL modules
as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I 
don't see why the
module itself could not be included in the RC branch. The only piece that 
really has to be checked
is config.m4, and in this scenario there doesn't appear to be 
problems(efficient or not). As long as
the withval test is valid, and the module is not enabled by default it 
really shouldn't affect php
as a whole. I believe that this is a fine exception to the rule.

However, if fastcgi is being labled stable, then, IMHO, I believe it 
should wait for thorough testing,
and the next freeze.

I think that Sascha, and Jani have concerns with this being the first 
domino in a series of continually
growing exceptions to the release process. An RP ruleset is one of those 
things that is often considered
  "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed 
 valid points about the functionality
  being important and shouldn't wait.  Which, if there is big need for it, 
 why can't there be a compromise?

Perhaps everyone should consider altering the RP ruleset, to include an 
exception about adding new
modules.

If the exception policy was in place here are some questions of thought:
What would be necessary to make it safe to php in a whole?
What should the requirements be to allow this to happen ( ex. a lot of 
user demand, replaces something considered unstable) ?
Should this require any re-testing?
Should this require x amount of RCs to follow and how many?
Should there be a vote on whether or not to allow the module in?
Is this module something that should first be released as an add-on?

I honestly agree with both positions on this one, and I think  good can 
come from both of them : )

-Jason




- Original Message -
From: "Zeev Suraski" [EMAIL PROTECTED]
To: "Sascha Schumann" [EMAIL PROTECTED]
Cc: "PHP Developers Mailing List" [EMAIL PROTECTED]; "PHP Quality 
Assurance Team Mailing List" [EMAIL PROTECTED]
Sent: Wednesday, March 21, 2001 1:33 PM
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: 
php4(PHP_4_0_5) /sapi/fastcgi


  But I referred to 4.0.3pl1 :)
 
  At 21:23 21/3/2001, Sascha Schumann wrote:
The Apache module issue was a security problem.  A fairly major 
 one, too.
  
   Yes, that is why I mentioned 4.0.4pl1 as an exception in an
   earlier email.
  
   - Sascha Experience IRCG
 http://schumann.cx/http://schumann.cx/ircg
 
  --
  Zeev Suraski [EMAIL PROTECTED]
  CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/
 
 
  --
  PHP Development Mailing List http://www.php.net/
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  To contact the list administrators, e-mail: [EMAIL PROTECTED]
 

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 22:19 21/3/2001, Jason Greene wrote:
If the exception policy was in place here are some questions of thought:
What would be necessary to make it safe to php in a whole?

I'd say that a module that has no effect on building PHP is fine to add as 
an experimental module.  The only reason I believe we need at least one RC 
afterwards, is to ensure that trivial problems weren't introduced (mostly, 
a broken build).

What should the requirements be to allow this to happen ( ex. a lot of 
user demand, replaces something considered unstable) ?

I think that these are the same requirements for any other module that we 
decide to admit to the tree.  Since it's not a big deal, if it belongs in 
the PHP 4.0 tree, then it's ok to add it whilst in RC's.

Should this require any re-testing?
Should this require x amount of RCs to follow and how many?

IMHO, one more RC.

Should there be a vote on whether or not to allow the module in?

We don't have a body with 'jurisdiction' other than the PHP Group, so I'd 
say no;  Whatever loose guidelines we use today to admit new modules can 
apply here as well.

Is this module something that should first be released as an add-on?

I honestly agree with both positions on this one, and I think  good can 
come from both of them : )

I think that by saying you agree with both positions you attribute to me 
things that I didn't say :)  I'm all in favour of a stable release 
process.  I'm not in favour in considering the release process guidelines 
as 'holy', and if I or anybody else thinks they can be improved, the right 
step would be to raise it for discussion.  As I said to Hartmut, the minute 
bureaucracy becomes sacred, you know you're doing something wrong.  I 
considered the fact that the release process did not account for new 
experimental modules a limitation of the release process.  Even the US 
constitution required a few amendments before they got it right :)

Zeev


--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Zeev Suraski

At 16:38 21/3/2001, Thies C. Arntzen wrote:
 i fully agree to sascha. plus i see no real reason to include
 a new module once we are in "release-process". new modules
 are by default not "producition-stable" so why hurry to
 include them in a "official-release"?

For wide exposure.  SAPI modules will not get very far without it.

 the no. 1 (and maybe only goal) for a release should be
 stability and well tested functionality IMHO.

Stability is irrelevant with new modules - they did not exist before, so 
they can't be less stable, and figuring whether their addition breaks PHP 
is trivial, and would be discovered in a second if they manage to do that 
somehow.  New modules are no different from any of the unstable modules 
that exist in PHP, and there are plenty of them.

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Jani Taskinen

On Tue, 20 Mar 2001, Andi Gutmans wrote:

At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote:
On Tue, 20 Mar 2001, Andi Gutmans wrote:

  andi  Tue Mar 20 10:13:21 2001 EDT
 
Added files: (Branch: PHP_4_0_5)
  /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI config.m4
fastcgi.c php.sym php_fastcgi.h
Log:
- MFH

erhm, I thought that during the Release Process no new things were being
added

The SAPI extension was never used by anyone before so there's no harm in
adding it (this is not changing/patching existing functionality).
It does make two changes to two build files but I took a very close look at
them and it doesn't seem like they can cause us problems.

Still, it's against the rules.. :) And the config.m4 for it
isn't..hmm..optimized.

--Jani



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Andi Gutmans

At 07:41 PM 3/20/2001 +0100, Jani Taskinen wrote:
On Tue, 20 Mar 2001, Andi Gutmans wrote:

 At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote:
 On Tue, 20 Mar 2001, Andi Gutmans wrote:
 
   andi  Tue Mar 20 10:13:21 2001 EDT
  
 Added files: (Branch: PHP_4_0_5)
   /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI 
 config.m4
 fastcgi.c php.sym php_fastcgi.h
 Log:
 - MFH
 
 erhm, I thought that during the Release Process no new things were being
 added
 
 The SAPI extension was never used by anyone before so there's no harm in
 adding it (this is not changing/patching existing functionality).
 It does make two changes to two build files but I took a very close look at
 them and it doesn't seem like they can cause us problems.

Still, it's against the rules.. :) And the config.m4 for it
isn't..hmm..optimized.

Jani,

I couldn't find any indication that this can break any of the other sapi 
builds so I don't think there's a problem with adding it.
Adding it now will give it more visibility and more people will be able to 
test it especially Zeus users who are in great need of it.
If the fastcgi sapi extension doesn't work well isn't important as long as 
it doesn't break anything else.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Jani Taskinen

On Tue, 20 Mar 2001, Andi Gutmans wrote:

I couldn't find any indication that this can break any of the other sapi
builds so I don't think there's a problem with adding it.

Okay. But still I find it very annoying that we don't follow the
rules we have created. Just for the record. :)

And I hope someone really tests this before release. (I know I won't :)

--Jani


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Andi Gutmans

At 07:57 PM 3/20/2001 +0100, Jani Taskinen wrote:
On Tue, 20 Mar 2001, Andi Gutmans wrote:

 I couldn't find any indication that this can break any of the other sapi
 builds so I don't think there's a problem with adding it.

Okay. But still I find it very annoying that we don't follow the
rules we have created. Just for the record. :)

And I hope someone really tests this before release. (I know I won't :)

Well everyone testing RC2 will because what will be tested is not fastcgi 
but that nothing else broke due to the patch, and I pretty much went 
through the changes which can effect non-fastcgi users to make sure it's OK.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Zeev Suraski

At 20:57 20/3/2001, Jani Taskinen wrote:
On Tue, 20 Mar 2001, Andi Gutmans wrote:

 I couldn't find any indication that this can break any of the other sapi
 builds so I don't think there's a problem with adding it.

Okay. But still I find it very annoying that we don't follow the
rules we have created. Just for the record. :)

Time for the 1st amendment? :)

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Zeev Suraski

It's an inherent 'feature' of opensource projects, which has its advantages 
and disadvantages.  One of the good things about OSS is the relatively 
short 'time to market'.  The price is that you have to be willing to accept 
buglets.  The trick is to find the right mixture between time to market and 
the risk of instability.

In my humble opinion (humility is a virtue), new modules are fine to add 
while in the release process, as long as there's at least one RC after 
them, to ensure they don't mess up the build or anything trivial like 
that.  It takes 2-3 months between each and every release, and it'd be a 
shame for the new module author to receive wide exposure and feedback for 
his new code.  In my opinion, the CVS rules should be changed to reflect 
that, just to make Jani happy, or we'd stay outlaws in his mind forever :)

Zeev

At 23:21 20/3/2001, Sascha Schumann wrote:
  The SAPI extension was never used by anyone before so there's no harm in
  adding it (this is not changing/patching existing functionality).
  It does make two changes to two build files but I took a very close look at
  them and it doesn't seem like they can cause us problems.

 Regardless of how simple a change may look, it can cause
 problems.  IMNSHO, only well-tested changes for critical bugs
 should be applied to a release branch ever, otherwise we will
 never get rid of patchlevel releases.  Our continous need for
 those point to a quite embarrasing problem in our release
 process which we finally need to overcome.

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Sascha Schumann

 The SAPI extension was never used by anyone before so there's no harm in
 adding it (this is not changing/patching existing functionality).
 It does make two changes to two build files but I took a very close look at
 them and it doesn't seem like they can cause us problems.

Regardless of how simple a change may look, it can cause
problems.  IMNSHO, only well-tested changes for critical bugs
should be applied to a release branch ever, otherwise we will
never get rid of patchlevel releases.  Our continous need for
those point to a quite embarrasing problem in our release
process which we finally need to overcome.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5)/sapi/fastcgi

2001-03-20 Thread Joey Smith

Well, IIUC, this is really all Jani is trying to say...RC2 is could be
considered invalid now...

On Tue, 20 Mar 2001, Zeev Suraski wrote the following to Sascha Schumann :

 In my humble opinion (humility is a virtue), new modules are fine to add 
 while in the release process, as long as there's at least one RC after 
 them




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-20 Thread Jani Taskinen

On Tue, 20 Mar 2001, Zeev Suraski wrote:

his new code.  In my opinion, the CVS rules should be changed to reflect
that, just to make Jani happy, or we'd stay outlaws in his mind forever :)

:)

--Jani


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]