Re: [PHP-DEV] 4.0.5: Merge Request

[Andi Gutmans]

At 12:11 AM 4/26/2001 -0400, Sterling Hughes wrote:
>I'll agree that the inverse of the above is true ;)))
>
>But if you look at it over time, it averages out, making the net
>effect equal 0.
>
>anyway, I think we agree on the math, we just disagree on whether the
>short term affect is worth it.
>
>regardless of the outcome, I'm fine though, I think that soon enough
>the releases (because of there nature) will become a feature freeze (as
>more features get added, there are less features that need to be added,
>plus the core is getting smaller soon, so the net effect will be more bug
>fix releases and less feature releases)...

It's psychological and a state of mind thing. If all developers know that 
for the next few days they shouldn't concentrate on adding new 
functionality but should help out the project by trying to fix bugs you'll 
end up having more bugs fixed.
I think usually developers prefer to work on new functionality and won't 
help with other bugs too much. If there is a call for this and some time 
frame trying to get everyone to work together that could make a difference 
(and respect to the guy who fixes the most amount of bugs ;)
By the way, it's not the end of the world if someone developers code on his 
machine at home and only commits it a few days later. You're not forcing 
him to stop development because he can still do it at home but at least you 
get the state of mind across and I think a lot of developers will join in.
Andi
Andi


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Andrei Zmievski wrote:

> On Wed, 25 Apr 2001, Sterling Hughes wrote:
> > Naturally, but what does waiting 7 (an arbitrary number) of days do to
> > make the new feature have less bugs.  The way I see it, the sooner the
> > feature is in there, the sooner the bug gets identified the sooner we're
> > able to fix it, the better.  Meanwhile, we can all still be working on
> > fixing older bugs.
>
> Look it's simple. We have x developers and QA people able to fix bugs.
> For a certain RC we have y bugs. If you add a new feature, you will
> probably introduce z bugs. Now, x/y is the amount of effort per bug
> without the new feature, and it is certainly more than x/(y+z) - with
> the new feature. Simple math.
>

I'll agree that the inverse of the above is true ;)))

But if you look at it over time, it averages out, making the net
effect equal 0.

anyway, I think we agree on the math, we just disagree on whether the
short term affect is worth it.

regardless of the outcome, I'm fine though, I think that soon enough
the releases (because of there nature) will become a feature freeze (as
more features get added, there are less features that need to be added,
plus the core is getting smaller soon, so the net effect will be more bug
fix releases and less feature releases)...

-sterling


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andrei Zmievski]

On Wed, 25 Apr 2001, Sterling Hughes wrote:
> Naturally, but what does waiting 7 (an arbitrary number) of days do to
> make the new feature have less bugs.  The way I see it, the sooner the
> feature is in there, the sooner the bug gets identified the sooner we're
> able to fix it, the better.  Meanwhile, we can all still be working on
> fixing older bugs.

Look it's simple. We have x developers and QA people able to fix bugs.
For a certain RC we have y bugs. If you add a new feature, you will
probably introduce z bugs. Now, x/y is the amount of effort per bug
without the new feature, and it is certainly more than x/(y+z) - with
the new feature. Simple math.

-Andrei

The main reason Santa is so jolly is because he knows where
all the bad girls live.  -- George Carlin

-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Andrei Zmievski wrote:

> On Wed, 25 Apr 2001, Sterling Hughes wrote:
> > I actually think the general idea is good, have a release where all the
> > regular contributors agree to work on fixing bugs.  Or like the debian
> > folk do, have a bug squashing party.  I'm just saying that a feature
> > freeze seems un-necessary, I see no reason why we can't have our cake
> > and eat it too...
>
> Because new features introduce new bugs.
>

Naturally, but what does waiting 7 (an arbitrary number) of days do to
make the new feature have less bugs.  The way I see it, the sooner the
feature is in there, the sooner the bug gets identified the sooner we're
able to fix it, the better.  Meanwhile, we can all still be working on
fixing older bugs.

-Sterling


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andrei Zmievski]

On Wed, 25 Apr 2001, Sterling Hughes wrote:
> I actually think the general idea is good, have a release where all the
> regular contributors agree to work on fixing bugs.  Or like the debian
> folk do, have a bug squashing party.  I'm just saying that a feature
> freeze seems un-necessary, I see no reason why we can't have our cake
> and eat it too...

Because new features introduce new bugs.

-Andrei

Any sufficiently advanced bug is
indistinguishable from a feature.
-- Rich Kulawiec

-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Jani Taskinen wrote:

> On Wed, 25 Apr 2001, Sterling Hughes wrote:
>
> >On Thu, 26 Apr 2001, Jani Taskinen wrote:
> >
> >> On Tue, 24 Apr 2001, Sterling Hughes wrote:
> >>
> >> >I think its not a bad idea to encourage (even more :) bug fixing for the
> >> >next release, but I don't think restricting valuable and/or needed
> >> >features is a good idea.
> >>
> >> You're just lazy. :)
> >
> >I really don't see that in my statement.  I'm saying is that going
> >gung-ho at fixing bugs is great, but I don't see any reason to reject
> >work because it is a feature rather than a bug fix.
>
> Okay, wrong choice of word. I meant to say: You're just impatient.
> Why couldn't you wait with those features until the bug fixing period
> would be over? And adding new features is usually also adding of new
> bugs..
>

I could, and it wouldn't be the end of the world...  I just don't see the
point in restricting good work, by setting up  a bug fixing freeze.  If
we were to have such a thing, I personally would spend the time fixing
bugs, however, if another developer has a really cool feature he wants to
add, I see no reason why it shouldn't go in.

> >> There are these 'bugs' with type 'Feature/Change request'... so?
> >There not really "bugs" in the terms that I think everyone else is
> >referring to a bug as.  Its just convient to place these in the bugs db.
>
> Hrhm..forget about it.
>
> Anyway, we can forget this as most of the developers seem to object the
> idea of 'bug fixing freeze'. (most of them have kept their mouths shut)
>

I actually think the general idea is good, have a release where all the
regular contributors agree to work on fixing bugs.  Or like the debian
folk do, have a bug squashing party.  I'm just saying that a feature
freeze seems un-necessary, I see no reason why we can't have our cake
and eat it too...

-Sterling


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[derick]

On Thu, 26 Apr 2001, Zeev Suraski wrote:

> At 17:56 26/4/2001, Jani Taskinen wrote:
> >Anyway, we can forget this as most of the developers seem to object the
> >idea of 'bug fixing freeze'. (most of them have kept their mouths shut)
>
> I'm still in favour of doing this for 4.0.6.

I think it's wise to do too. Every x minor releases we should this I
think. Where x is a number between 3 and 5. This doesn't harm anything,
and my guess is that it certainly makes PHP more stable (then it already
is).

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Zeev Suraski]

At 17:56 26/4/2001, Jani Taskinen wrote:
>Anyway, we can forget this as most of the developers seem to object the
>idea of 'bug fixing freeze'. (most of them have kept their mouths shut)

I'm still in favour of doing this for 4.0.6.

Zeev


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Sterling Hughes]

On Thu, 26 Apr 2001, Jani Taskinen wrote:

> On Tue, 24 Apr 2001, Sterling Hughes wrote:
>
> >I think its not a bad idea to encourage (even more :) bug fixing for the
> >next release, but I don't think restricting valuable and/or needed
> >features is a good idea.
>
> You're just lazy. :)

I really don't see that in my statement.  I'm saying is that going
gung-ho at fixing bugs is great, but I don't see any reason to reject
work because it is a feature rather than a bug fix.

> There are these 'bugs' with type 'Feature/Change request'... so?
>

There not really "bugs" in the terms that I think everyone else is
referring to a bug as.  Its just convient to place these in the bugs db.

-Sterling


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Jani Taskinen]

On Wed, 25 Apr 2001, Sterling Hughes wrote:

>On Thu, 26 Apr 2001, Jani Taskinen wrote:
>
>> On Tue, 24 Apr 2001, Sterling Hughes wrote:
>>
>> >I think its not a bad idea to encourage (even more :) bug fixing for the
>> >next release, but I don't think restricting valuable and/or needed
>> >features is a good idea.
>>
>> You're just lazy. :)
>
>I really don't see that in my statement.  I'm saying is that going
>gung-ho at fixing bugs is great, but I don't see any reason to reject
>work because it is a feature rather than a bug fix.

Okay, wrong choice of word. I meant to say: You're just impatient.
Why couldn't you wait with those features until the bug fixing period
would be over? And adding new features is usually also adding of new
bugs..

>> There are these 'bugs' with type 'Feature/Change request'... so?
>There not really "bugs" in the terms that I think everyone else is
>referring to a bug as.  Its just convient to place these in the bugs db.

Hrhm..forget about it.

Anyway, we can forget this as most of the developers seem to object the
idea of 'bug fixing freeze'. (most of them have kept their mouths shut)

--Jani



-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Jani Taskinen]

On Tue, 24 Apr 2001, Sterling Hughes wrote:

>I think its not a bad idea to encourage (even more :) bug fixing for the
>next release, but I don't think restricting valuable and/or needed
>features is a good idea.

You're just lazy. :)
There are these 'bugs' with type 'Feature/Change request'... so?

--Jani


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Rasmus Lerdorf]

> Andi Gutmans ([EMAIL PROTECTED]) wrote:
> > For the QA guys it might be nice to be able to flag certain bugs in the bug
> > database and then automatically create a summary page which could be sent
> > to php-dev. However, I think it would take too much time to get started.
> > Maybe just manually creating a list with a one line description of bug #,
> > where the bug is and a short short summary would be best. This could be
> > sent to php-dev.
>
> Is adding a severity to the bugdb that hard, or is reporting that
> fiddly?

It's actually not that hard at all.  It's more a matter of defining
exactly what we want it to do.  And also figuring out what the guys who
are working on a new bug database are doing.

I think our current bug database is quite functional and most importantly
quite simple to use for everyone.  It has served us well.  We need to make
sure a rewrite isn't going to make this stuff overly complex.

-Rasmus


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Thomas Swan]

At 4/25/2001 01:04 AM, Rasmus Lerdorf wrote:

*SNIP*

>The question right now is how to best implement this.  Do we add something
>to the bug database to flag bugs in some manner and have a release
>candidate summary page?
>
>Or do we separate it out of the bug database and maintain the list
>manually?

On suggestion is to have a "vote" for a bug.  The more votes the more 
attention should be devoted to it.  In Bugzilla you have the option of 
voting for bugs although I'm not exactly sure how much weight is attributed 
to the score.  While it shouldn't be the only metric, I think it could help 
on solving some contingencies for attention.

Food for thought...


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Stephen van Egmond]

Andi Gutmans ([EMAIL PROTECTED]) wrote:
> For the QA guys it might be nice to be able to flag certain bugs in the bug 
> database and then automatically create a summary page which could be sent 
> to php-dev. However, I think it would take too much time to get started. 
> Maybe just manually creating a list with a one line description of bug #, 
> where the bug is and a short short summary would be best. This could be 
> sent to php-dev.

Is adding a severity to the bugdb that hard, or is reporting that
fiddly?

Actually, could the people who maintain the bugdb get in touch with me
offline at [EMAIL PROTECTED]? (Please take php-dev out of the subject
so it doesn't just show up in my php-dev folder)? I have some ideas.


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andrei Zmievski]

On Tue, 24 Apr 2001, Sterling Hughes wrote:
> Hrmm..
> 
> I think its not a bad idea to encourage (even more :) bug fixing for the
> next release, but I don't think restricting valuable and/or needed
> features is a good idea.

Grr.. I'd really like for 4.0.5 to come out soon, it's holding up a
number of my projects that depend on new features in it.. :)

-Andrei

"The galaxy is, in other words, an immensely, intrinsically,
and inexhaustibly interesting place." -- Iain M. Banks

-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Jon Parise]

On Tue, Apr 24, 2001 at 11:04:33PM -0700, Rasmus Lerdorf wrote:

> Yes, but that is my point. They should not be asking people to fix bugs.
> They should simply be identifying and prioritizing the bugs.  As a group
> we need to fix the bugs.  Jani is complaining that they are ignored, so we
> need to change the atmosphere and remove that aspect from their duties.
> We are not going to change the way developers do their day-to-day jobs by
> much.  But by changing the approach to one that is centered around an
> itemized list of issues I think we will completely change how things work.
> Imagine if there is only 1 criticl bug left on the list and it is in a
> piece of code you wrote?  Everyone sees this list and everyone can see
> that as soon as this bug is fixed the release can go out.  That will
> motivate a developer into holding off on playing with cool new features
> and taking a look at the bug.
> 
> The question right now is how to best implement this.  Do we add something
> to the bug database to flag bugs in some manner and have a release
> candidate summary page?
> 
> Or do we separate it out of the bug database and maintain the list
> manually?
 
I don't have any personal experience with the Mozilla "solution"
to this issue, but I'm sure someone else where must know more
about it than me.

Anyway, they appear to have some sort of "voting" system in
place, tied into Bugzilla.  Each user or developer votes on which
bugs s/he thinks should be closed before the next milestone is
released.  If a bug receives enough votes, it becomes a required
bug fix.

Adopting a system like this would mean hacking on our current bug
system, and I don't have time or code to back that up right now
(although I really wish I could).  Perhaps someone else will be
able to step in there, though.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Cynic]

At 07:35 25.4. 2001, Rasmus Lerdorf wrote the following:
-- 
>Nobody is talking about such an illusion.  Let's not lose track of what
>caused this ruckus.  A crash bug was found and fixed in a mainstream
>extension.  It was just before a release.  So the release was put off for
>a couple of days to get this fix in.  I see absolutely nothing wrong with
>this.

I don't think the bug fix was the cause. It triggered the debate, but
the debate had been here before, and will return eventually. I remember 
a very heated debate in IIRC about a year ago. A feature-freeze periods 
were proposed, and dismissed. I think they should (and could) be employed.
I know it's not funny to clean up after oneself (or even others), but 
other OS projects use stricter models than PHP does, and thrive. 
I know you're subscribed to new-httpd@, do you think PHP group could 
adopt some of their policies?
BTW, it's fun at times to watch new-httpd@ discussing the same things that
are discussed on php-qa@ and php-dev@.

(...)

>release branch, but here is where I would like the QA team or someone to
>step up and create a list of issues (likely just a list of bug id numbers)
>that they deem to be significant issues with the release branch.  It
>should not be the QA team's job to track down developers and try to
>convince them to fix bugs.
>
>eg.
>
>Release branch 4.0.87
>
>  Showstoppers: #20457, #24099
>  Serious: #24, #354354, #546543
>  Moderate: #535436, #45326543, #5443543
>
>Developers like finite-looking lists like this.  They can see an end to
>the work.  Fix 5 bugs and we are good to go for the release.  Obviously
>there will still be bugs, but at least this would be an organized approach
>to it.

This would be certainly nice, but for the moment the PHP 4 bug report being
sent to php-dev@ again (after a ... two months? pause) would suffice. :)

>-Rasmus
--end of quote-- 


Cynic


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andi Gutmans]

At 11:04 PM 4/24/2001 -0700, Rasmus Lerdorf wrote:
> > Having a better defined/reproduced list of bugs is a must and if the QA
> > team can do that PHP will definitely benefit from it. However, today when
> > they ask people to fix bugs they are often not fixed and I don't even think
> > that they are necessarily looked at. That is why a defined "everyone join
> > forces to kill the bugs" period would be a good thing. And whoever doesn't
> > help isn't allowed to hack on his extension anymore (Just kidding :).
>
>Yes, but that is my point. They should not be asking people to fix bugs.
>They should simply be identifying and prioritizing the bugs.  As a group
>we need to fix the bugs.  Jani is complaining that they are ignored, so we
>need to change the atmosphere and remove that aspect from their duties.
>We are not going to change the way developers do their day-to-day jobs by
>much.  But by changing the approach to one that is centered around an
>itemized list of issues I think we will completely change how things work.
>Imagine if there is only 1 criticl bug left on the list and it is in a
>piece of code you wrote?  Everyone sees this list and everyone can see
>that as soon as this bug is fixed the release can go out.  That will
>motivate a developer into holding off on playing with cool new features
>and taking a look at the bug.
>
>The question right now is how to best implement this.  Do we add something
>to the bug database to flag bugs in some manner and have a release
>candidate summary page?
>
>Or do we separate it out of the bug database and maintain the list
>manually?

For the QA guys it might be nice to be able to flag certain bugs in the bug 
database and then automatically create a summary page which could be sent 
to php-dev. However, I think it would take too much time to get started. 
Maybe just manually creating a list with a one line description of bug #, 
where the bug is and a short short summary would be best. This could be 
sent to php-dev.


>I think this is something for the QA guys to bite into and answer if they
>agree that this sort of approach would improve their lives and make them
>less grumpy.

And the hackers will have to bite into the QA report because if they don't, 
then we get nowhere.

Andi


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Rasmus Lerdorf]

> Having a better defined/reproduced list of bugs is a must and if the QA
> team can do that PHP will definitely benefit from it. However, today when
> they ask people to fix bugs they are often not fixed and I don't even think
> that they are necessarily looked at. That is why a defined "everyone join
> forces to kill the bugs" period would be a good thing. And whoever doesn't
> help isn't allowed to hack on his extension anymore (Just kidding :).

Yes, but that is my point. They should not be asking people to fix bugs.
They should simply be identifying and prioritizing the bugs.  As a group
we need to fix the bugs.  Jani is complaining that they are ignored, so we
need to change the atmosphere and remove that aspect from their duties.
We are not going to change the way developers do their day-to-day jobs by
much.  But by changing the approach to one that is centered around an
itemized list of issues I think we will completely change how things work.
Imagine if there is only 1 criticl bug left on the list and it is in a
piece of code you wrote?  Everyone sees this list and everyone can see
that as soon as this bug is fixed the release can go out.  That will
motivate a developer into holding off on playing with cool new features
and taking a look at the bug.

The question right now is how to best implement this.  Do we add something
to the bug database to flag bugs in some manner and have a release
candidate summary page?

Or do we separate it out of the bug database and maintain the list
manually?

I think this is something for the QA guys to bite into and answer if they
agree that this sort of approach would improve their lives and make them
less grumpy.

-Rasmus


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andi Gutmans]

At 10:35 PM 4/24/2001 -0700, Rasmus Lerdorf wrote:
> > At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote:
> > >While I'd say Jani's letter was slightly over emotional ;), he does have a
> > >point.
> > >I think that taking a stop to look closely at the bugs database would be a
> > >good thing, and the turn of a new version is a good time to do
> > >it.  Deciding 4.0.6 won't include any significant new features, and that
> > >we'll start its release process after a bugs-database-cleaning period
> > >sounds like a good idea to me.
> >
> > Well I was saying exactly what Jani is saying. That if you want a bug free
> > minor version then you have to be aware of all the existing crash bugs in
> > the bugs database and not live in the illusion that this last 4.0.5 crash
> > bug fix creates now a stable version. I don't think every crash bug can be
> > a show stopper. Our releases would slow down to a halt.
>
>Nobody is talking about such an illusion.  Let's not lose track of what
>caused this ruckus.  A crash bug was found and fixed in a mainstream
>extension.  It was just before a release.  So the release was put off for
>a couple of days to get this fix in.  I see absolutely nothing wrong with
>this.

Neither do I.


>Of course there are still bugs.  And yes there are still serious bugs
>lurking.  But none we have a known and tested fix for.

Yes but for example the crash bug I fixed in foreach(). I don't think it 
was a showstopper. It ended up slipping in because there was another RC 
anyway (and it was a one liner) but what I meant is that not all crash bugs 
are show stoppers.


> > Anyway, I think it's a good idea to decide on a one to two week intensive
> > period where no features are added and all developers work hard on closing
> > crash bugs and other serious bugs. The problem is that there will be lots
> > of developers who will want their very important patches going into 4.0.6
> > and quite a few who won't be bothered to do the tough job. I'm not sure
> > this would work.
>
>This will definitely not work as "all developers" are at very different
>stages of development.  Some extensions are very young and evolving
>quickly right now.  Telling a developer with such an extension to stop
>developing the extension and only fix bugs doesn't make much sense.


I disagree. I don't think having developers take off a couple of days from 
their "stage of development" and help the greater PHP cause is a big deal. 
After all it is these developers that can help fix bugs, and well what can 
we do, bugs aren't necessarily fixed by their authors.
It's much more fun coding and writing your own extension, and it's a good 
thing, but it doesn't mean you can't do some of the dirty work for a couple 
of days. That suggestion to look at the Debian model is a good idea IMO.


>The realistic way to do this, and the way I thought we had agreed on, is
>to create a release branch at some semi-stable point and not add new
>features to it but focus on fixing the most serious bugs in it.  And yes,
>I agree that it would be good if we could get more developers to focus on
>the release branch and devote more cycles to tracking down issues in the
>release branch, but here is where I would like the QA team or someone to
>step up and create a list of issues (likely just a list of bug id numbers)
>that they deem to be significant issues with the release branch.  It
>should not be the QA team's job to track down developers and try to
>convince them to fix bugs.
>
>eg.
>
>Release branch 4.0.87
>
>   Showstoppers: #20457, #24099
>   Serious: #24, #354354, #546543
>   Moderate: #535436, #45326543, #5443543
>
>Developers like finite-looking lists like this.  They can see an end to
>the work.  Fix 5 bugs and we are good to go for the release.  Obviously
>there will still be bugs, but at least this would be an organized approach
>to it.

Having a better defined/reproduced list of bugs is a must and if the QA 
team can do that PHP will definitely benefit from it. However, today when 
they ask people to fix bugs they are often not fixed and I don't even think 
that they are necessarily looked at. That is why a defined "everyone join 
forces to kill the bugs" period would be a good thing. And whoever doesn't 
help isn't allowed to hack on his extension anymore (Just kidding :).

Andi


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Rasmus Lerdorf]

> At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote:
> >While I'd say Jani's letter was slightly over emotional ;), he does have a
> >point.
> >I think that taking a stop to look closely at the bugs database would be a
> >good thing, and the turn of a new version is a good time to do
> >it.  Deciding 4.0.6 won't include any significant new features, and that
> >we'll start its release process after a bugs-database-cleaning period
> >sounds like a good idea to me.
>
> Well I was saying exactly what Jani is saying. That if you want a bug free
> minor version then you have to be aware of all the existing crash bugs in
> the bugs database and not live in the illusion that this last 4.0.5 crash
> bug fix creates now a stable version. I don't think every crash bug can be
> a show stopper. Our releases would slow down to a halt.

Nobody is talking about such an illusion.  Let's not lose track of what
caused this ruckus.  A crash bug was found and fixed in a mainstream
extension.  It was just before a release.  So the release was put off for
a couple of days to get this fix in.  I see absolutely nothing wrong with
this.

Of course there are still bugs.  And yes there are still serious bugs
lurking.  But none we have a known and tested fix for.

> Anyway, I think it's a good idea to decide on a one to two week intensive
> period where no features are added and all developers work hard on closing
> crash bugs and other serious bugs. The problem is that there will be lots
> of developers who will want their very important patches going into 4.0.6
> and quite a few who won't be bothered to do the tough job. I'm not sure
> this would work.

This will definitely not work as "all developers" are at very different
stages of development.  Some extensions are very young and evolving
quickly right now.  Telling a developer with such an extension to stop
developing the extension and only fix bugs doesn't make much sense.

The realistic way to do this, and the way I thought we had agreed on, is
to create a release branch at some semi-stable point and not add new
features to it but focus on fixing the most serious bugs in it.  And yes,
I agree that it would be good if we could get more developers to focus on
the release branch and devote more cycles to tracking down issues in the
release branch, but here is where I would like the QA team or someone to
step up and create a list of issues (likely just a list of bug id numbers)
that they deem to be significant issues with the release branch.  It
should not be the QA team's job to track down developers and try to
convince them to fix bugs.

eg.

Release branch 4.0.87

  Showstoppers: #20457, #24099
  Serious: #24, #354354, #546543
  Moderate: #535436, #45326543, #5443543

Developers like finite-looking lists like this.  They can see an end to
the work.  Fix 5 bugs and we are good to go for the release.  Obviously
there will still be bugs, but at least this would be an organized approach
to it.

-Rasmus


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Stephen van Egmond]

Andi Gutmans ([EMAIL PROTECTED]) wrote:
> features (also because it has enough additional features already which are 
> enough for another minor version), but the developers need to actually go 
> through the bugs database and work on those crash bugs. It's not that easy 
> to get everyone to work on them.

The Debian project uses a practice which may be useful.

Bugs are identified by project leaders as release-critical. 
Release-critical is a bug severity level which bugs (crashers,
cosmetic, whatever) can get promoted to.

There's a page giving stats on RC bugs:
http://master.debian.org/~wakkerma/bugs/

And approximately monthly bug squashing parties held on IRC:
http://lwn.net/2001/0222/a/db-bugsquash.php3

My suggestion, having watched a few open-source projects structured
similarly to PHP, is to declare a particular date as a freeze date,
with pressure NOT to commit major overhauls increasing as the freeze
approached.  At the freeze, a CVS branch is created and the bug
squashing party begins - release critical bugs only!

Once RC bugs get cleared, the branch changes get merged back into the
mainline and development resumes until it's time to release again.


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andi Gutmans]

At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote:
>While I'd say Jani's letter was slightly over emotional ;), he does have a 
>point.
>I think that taking a stop to look closely at the bugs database would be a 
>good thing, and the turn of a new version is a good time to do 
>it.  Deciding 4.0.6 won't include any significant new features, and that 
>we'll start its release process after a bugs-database-cleaning period 
>sounds like a good idea to me.

Well I was saying exactly what Jani is saying. That if you want a bug free 
minor version then you have to be aware of all the existing crash bugs in 
the bugs database and not live in the illusion that this last 4.0.5 crash 
bug fix creates now a stable version. I don't think every crash bug can be 
a show stopper. Our releases would slow down to a halt.
I don't think it's enough to decide that 4.0.6 won't have additional 
features (also because it has enough additional features already which are 
enough for another minor version), but the developers need to actually go 
through the bugs database and work on those crash bugs. It's not that easy 
to get everyone to work on them.

Anyway, I think it's a good idea to decide on a one to two week intensive 
period where no features are added and all developers work hard on closing 
crash bugs and other serious bugs. The problem is that there will be lots 
of developers who will want their very important patches going into 4.0.6 
and quite a few who won't be bothered to do the tough job. I'm not sure 
this would work.
Andi


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Anil Madhavapeddy]

Zeev Suraski wrote:


> Deciding 4.0.6 won't include any significant new features,
> and that  we'll start its release process after a bugs-database
> -cleaning period sounds like a good idea to me.

So why restrict it to just the next release?  It might make a lot of
sense to have an RC candidate much more often, but with a longer QA
period to fix all these bugs.  Kind of like FreeBSD; have a -current,
and a -stable branch.  It's sort of been going that way with the 4.0.5
release (there's been a lot of uptake on merging bugfixes, but not
adding new features, except for FastCGI).

Anil


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Sterling Hughes]

On Wed, 25 Apr 2001, Zeev Suraski wrote:

> While I'd say Jani's letter was slightly over emotional ;), he does have a
> point.
> I think that taking a stop to look closely at the bugs database would be a
> good thing, and the turn of a new version is a good time to do
> it.  Deciding 4.0.6 won't include any significant new features, and that
> we'll start its release process after a bugs-database-cleaning period
> sounds like a good idea to me.
>

Hrmm..

I think its not a bad idea to encourage (even more :) bug fixing for the
next release, but I don't think restricting valuable and/or needed
features is a good idea.

-Sterling



> Zeev
>
>
> At 23:44 24/4/2001, Jani Taskinen wrote:
> >On Tue, 24 Apr 2001, Rasmus Lerdorf wrote:
> >
> > >An easily reproducable segfault in a common PHP extension is a serious
> > >issue which could lead to potential security breaches and thus lots of bad
> > >mojo from nasty bugtraq postings.  If we know about such a segfault and we
> > >have a fix and go ahead and release a "stable" package without this fix
> > >then our entire QA process is a joke.  If we find such bugs before a
> > >release, we fix them.  That's what the process is for.
> >
> >Have you checked the bug database lately?
> >There are 43 open reports with bug type 'Reproducible crash'.
> >There are actually even more of them. I can easily reproduce
> >at least 10 bugs which cause segfaults. Those haven't been fixed yet.
> >Those haven't been fixed for a couple of releases now.
> >So, with your logic, we shouldn't release before all of them are fixed?
> >
> >(of course some of these crashes aren't any bugs in PHP. e.g. the IMAP
> >extension. The c-client that it relies on isn't really that stable. )
> >
> >The QA process as it is IS a joke. Without the support from the developers
> >there aren't any possible ways that it can ever succeed.
> >It isn't the QA people who fix bugs. They just test and report to developers
> >who should FIX those bugs. Some core developers seem to have forget this..
> >
> >On the other hand, there have been dozens of crash fixes + other
> >fixes in current RC. So why can't we release it, make many people
> >happy and start the release cycle (for 4.0.6) ? And what prevents us
> >from releasing new versions every month? As the QA process
> >is a joke we can skip that anyway... :-p
> >
> >I haven't seen ANY stable releases yet..where are those kept? :)
> >I have only seen release after release that PHP gets more and more
> >new features (with old buggy ones) and with new bugs.
> >
> >What I would like to see now is a code freeze so that people would have
> >to start fixing bugs instead of creating new features. Otherwise this
> >really is a neverending circle. But this will never happen, I guess.
> >Could we vote for this? :)
> >
> >I know it's more fun to create something new. But at least for
> >me it's a matter of honour that my code works as it's intented to..you
> >seem to disagree.
> >
> >--Jani
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >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 
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] 4.0.5: Merge Request

[Zeev Suraski]

While I'd say Jani's letter was slightly over emotional ;), he does have a 
point.
I think that taking a stop to look closely at the bugs database would be a 
good thing, and the turn of a new version is a good time to do 
it.  Deciding 4.0.6 won't include any significant new features, and that 
we'll start its release process after a bugs-database-cleaning period 
sounds like a good idea to me.

Zeev


At 23:44 24/4/2001, Jani Taskinen wrote:
>On Tue, 24 Apr 2001, Rasmus Lerdorf wrote:
>
> >An easily reproducable segfault in a common PHP extension is a serious
> >issue which could lead to potential security breaches and thus lots of bad
> >mojo from nasty bugtraq postings.  If we know about such a segfault and we
> >have a fix and go ahead and release a "stable" package without this fix
> >then our entire QA process is a joke.  If we find such bugs before a
> >release, we fix them.  That's what the process is for.
>
>Have you checked the bug database lately?
>There are 43 open reports with bug type 'Reproducible crash'.
>There are actually even more of them. I can easily reproduce
>at least 10 bugs which cause segfaults. Those haven't been fixed yet.
>Those haven't been fixed for a couple of releases now.
>So, with your logic, we shouldn't release before all of them are fixed?
>
>(of course some of these crashes aren't any bugs in PHP. e.g. the IMAP
>extension. The c-client that it relies on isn't really that stable. )
>
>The QA process as it is IS a joke. Without the support from the developers
>there aren't any possible ways that it can ever succeed.
>It isn't the QA people who fix bugs. They just test and report to developers
>who should FIX those bugs. Some core developers seem to have forget this..
>
>On the other hand, there have been dozens of crash fixes + other
>fixes in current RC. So why can't we release it, make many people
>happy and start the release cycle (for 4.0.6) ? And what prevents us
>from releasing new versions every month? As the QA process
>is a joke we can skip that anyway... :-p
>
>I haven't seen ANY stable releases yet..where are those kept? :)
>I have only seen release after release that PHP gets more and more
>new features (with old buggy ones) and with new bugs.
>
>What I would like to see now is a code freeze so that people would have
>to start fixing bugs instead of creating new features. Otherwise this
>really is a neverending circle. But this will never happen, I guess.
>Could we vote for this? :)
>
>I know it's more fun to create something new. But at least for
>me it's a matter of honour that my code works as it's intented to..you
>seem to disagree.
>
>--Jani
>
>
>
>--
>PHP Development Mailing List 
>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 
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] 4.0.5: Merge Request

[Rasmus Lerdorf]

> I can agree more the amount of times I have approached developers to say
> please fix this or what is the best way to get this fixed and just either
> 1) been ignored
> 2) told it doesnt matter
> 3) Told to fix it myself
> 4) In one extreme case (Ill leave the developer nameless) told its the users
> problem and
>not his.. he just writes the code doesnt make sure its bugless
>
> Now by no means all of the developers are guility of this but it seems I
> keep bugging those developers to get fixes which is unfair as its not always
> their extension. Shouldnt being an extension maintainer mean fixing bugs
> reported by the QA Team promptly? Rasmus you may say people here are
> voulenteers but by becoming in the project and being a maintainer they
> should be expected to fix bugs when asked. If they dont they loose their
> status as maintainer and we find someone else (unless they are away on
> holiday or somthing like that).

You can't force people to do anything they don't feel like doing.  It is
as simple as that.  No amount of posturing from me or anybody is going to
make a developer fix something he doesn't feel like fixing.  Taking away
maintainer status isn't going to do anything other than give us one less
resource to go to to try to fix issues.  Anybody listed as the author of
an extension is a maintainer for that extension to some extent.  And
anybody who wishes to step up and fix stuff is instantly a maintainer as
well.

As far as I am concerned the QA team should be testing and identifying
bugs in the release candidates and tagging things as either showstopper or
"that-can-wait" type of bugs.  If nobody steps up to fix a showstopper
bug, then there will be no release.  Eventually enough developers will get
annoyed at that and step up and fix that bug, but a showstopper is a
showstopper, hence the term.

You guys have done a great job going through the bug database and letting
the developers cut straight to the real problems instead of wasting time
trying to figure out what a report is actually trying to say.

There will always be disagreement on what is a showstopper bug and what
isn't.  In this case Chuck said it was a showstopper.  Few people know
more about the imap extension than Chuck, so I don't see why his decision
should be vetoed by QA or anybody.  If any significant developer steps up
and identifies a showstopper and provides a fix that needs to be
respected.

-Rasmus


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[James Moore]

> The QA process as it is IS a joke. Without the support from the developers
> there aren't any possible ways that it can ever succeed.
> It isn't the QA people who fix bugs. They just test and report to
> developers
> who should FIX those bugs. Some core developers seem to have forget this..

I can agree more the amount of times I have approached developers to say
please fix this or what is the best way to get this fixed and just either
1) been ignored
2) told it doesnt matter
3) Told to fix it myself
4) In one extreme case (Ill leave the developer nameless) told its the users
problem and
   not his.. he just writes the code doesnt make sure its bugless

Now by no means all of the developers are guility of this but it seems I
keep bugging those developers to get fixes which is unfair as its not always
their extension. Shouldnt being an extension maintainer mean fixing bugs
reported by the QA Team promptly? Rasmus you may say people here are
voulenteers but by becoming in the project and being a maintainer they
should be expected to fix bugs when asked. If they dont they loose their
status as maintainer and we find someone else (unless they are away on
holiday or somthing like that).

I promise you that QA'ing isnt fun but when you eventually get to the bottom
of a bug and can reproduce it well then a developer turns around and says
nothing or its not my problem its really demoralising and you just end up
thinking whats the point..

Somthing needs to be done and without a change of attitude from some of the
developers it is pointless the QA Team being in existance.

- James


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Rasmus Lerdorf]

> >An easily reproducable segfault in a common PHP extension is a serious
> >issue which could lead to potential security breaches and thus lots of bad
> >mojo from nasty bugtraq postings.  If we know about such a segfault and we
> >have a fix and go ahead and release a "stable" package without this fix
> >then our entire QA process is a joke.  If we find such bugs before a
> >release, we fix them.  That's what the process is for.
>
> Have you checked the bug database lately?
> There are 43 open reports with bug type 'Reproducible crash'.
> There are actually even more of them. I can easily reproduce
> at least 10 bugs which cause segfaults. Those haven't been fixed yet.
> Those haven't been fixed for a couple of releases now.
> So, with your logic, we shouldn't release before all of them are fixed?

You ignored what I said, "If we know about such a segfault and we have a fix"

And yes, if you can actually easily reproduce a segfault in a mainstream
module right now, then we have a showstopper and we hold until it is
fixed.  Please provide specifics.  Most of the ones I have looked at are
platform and library version specific and either not easily reproducible
nor common.

> The QA process as it is IS a joke. Without the support from the developers
> there aren't any possible ways that it can ever succeed.
> It isn't the QA people who fix bugs. They just test and report to developers
> who should FIX those bugs. Some core developers seem to have forget this..

QA is there to assure quality, not push out releases at all costs.
Pushing out a release without this imap fix would produce lower quality
rather than higher.  That should be the first priority of QA.

> What I would like to see now is a code freeze so that people would have
> to start fixing bugs instead of creating new features. Otherwise this
> really is a neverending circle. But this will never happen, I guess.
> Could we vote for this? :)

You are getting way off topic here.  You objected to a segfault fix being
merged into the release branch and thus slowing down the process.  This
was not a new feature.  For the most part no new features have gone into
the release branch.

> I know it's more fun to create something new. But at least for
> me it's a matter of honour that my code works as it's intented to..you
> seem to disagree.

Not at all.

-Rasmus


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Jani Taskinen]

On Tue, 24 Apr 2001, Rasmus Lerdorf wrote:

>An easily reproducable segfault in a common PHP extension is a serious
>issue which could lead to potential security breaches and thus lots of bad
>mojo from nasty bugtraq postings.  If we know about such a segfault and we
>have a fix and go ahead and release a "stable" package without this fix
>then our entire QA process is a joke.  If we find such bugs before a
>release, we fix them.  That's what the process is for.

Have you checked the bug database lately?
There are 43 open reports with bug type 'Reproducible crash'.
There are actually even more of them. I can easily reproduce
at least 10 bugs which cause segfaults. Those haven't been fixed yet.
Those haven't been fixed for a couple of releases now.
So, with your logic, we shouldn't release before all of them are fixed?

(of course some of these crashes aren't any bugs in PHP. e.g. the IMAP
extension. The c-client that it relies on isn't really that stable. )

The QA process as it is IS a joke. Without the support from the developers
there aren't any possible ways that it can ever succeed.
It isn't the QA people who fix bugs. They just test and report to developers
who should FIX those bugs. Some core developers seem to have forget this..

On the other hand, there have been dozens of crash fixes + other
fixes in current RC. So why can't we release it, make many people
happy and start the release cycle (for 4.0.6) ? And what prevents us
from releasing new versions every month? As the QA process
is a joke we can skip that anyway... :-p

I haven't seen ANY stable releases yet..where are those kept? :)
I have only seen release after release that PHP gets more and more
new features (with old buggy ones) and with new bugs.

What I would like to see now is a code freeze so that people would have
to start fixing bugs instead of creating new features. Otherwise this
really is a neverending circle. But this will never happen, I guess.
Could we vote for this? :)

I know it's more fun to create something new. But at least for
me it's a matter of honour that my code works as it's intented to..you
seem to disagree.

--Jani



-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Rasmus Lerdorf]

> >At 12:03 24/4/2001, Sascha Schumann wrote:
> >>On Tue, 24 Apr 2001, Zeev Suraski wrote:
> >>
> >> > At 03:02 24/4/2001, Anil Madhavapeddy wrote:
> >> > >It a bit of a showstopper for pretty much all web-based mail clients
> >> > >like IMP - people have been reporting their logs being littered with
> >> > >segfaults for a while now actually.
> >> >
> >> > Ok then, merge it in, and looks like we'll have to have RC8 after all.
> >>
> >> There has been a simple API change in Apache 2.0 as well
> >> which I'd like to accomodate.
> >
> >The race between world peace and PHP 4.0.5 is tightening by the minute :)
> >Anyway, let's say Wednesday evening (GMT) would be the last time to put in
> >changes;  RC8 goes out then;  4.0.5 goes out on Monday, unless there are
> >serious show stoppers.
>
> Or someone else comes and says "this tiny change is really needed by XXX
> software users around the world.." ?

An easily reproducable segfault in a common PHP extension is a serious
issue which could lead to potential security breaches and thus lots of bad
mojo from nasty bugtraq postings.  If we know about such a segfault and we
have a fix and go ahead and release a "stable" package without this fix
then our entire QA process is a joke.  If we find such bugs before a
release, we fix them.  That's what the process is for.

-Rasmus


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Zeev Suraski]

At 17:24 24/4/2001, Andi Gutmans wrote:
>Well you want me to merge the foreach() fix then? I don't because I prefer 
>it being tested for a while so that we don't have a pl1.

The plan is to release 4.0.5 four days after RC8.

>I don't think we fix all crash bugs every release. Mainly buffer overflows 
>are dangerous. Not double free()'s or de-referencing NULL pointers. But of 
>course, a lot of crashes are potentially dangerous but we would never have 
>any releases if we'd make sure that there's no chance PHP can crash, ever.

A known, easily reproducible crash is always more dangerous...  I have no 
doubt that PHP's code base includes quite a few different crashes today, 
but at least they're not known.

Zeev


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andi Gutmans]

Well you want me to merge the foreach() fix then? I don't because I prefer 
it being tested for a while so that we don't have a pl1.
I don't think we fix all crash bugs every release. Mainly buffer overflows 
are dangerous. Not double free()'s or de-referencing NULL pointers. But of 
course, a lot of crashes are potentially dangerous but we would never have 
any releases if we'd make sure that there's no chance PHP can crash, ever.

Andi

At 04:12 PM 4/24/2001 +0300, you wrote:
>Not necessarily;  Crash bugs can very often lead to security issues.  Of 
>course, it's a clearer cut if it's in a situation which is very likely to 
>happen.
>
>Zeev
>
>
>At 17:09 24/4/2001, Andi Gutmans wrote:
>>At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote:
>>>A reproducible crash bug in a mainstream module is a show stopper IMHO...
>>
>>I think you mean in a mainstream module and in a situation which has a 
>>high chance of happening.
>>Crash bugs which are 1 in a million don't necessarily need to be show 
>>stoppers.
>>
>>Andi
>
>--
>Zeev Suraski <[EMAIL PROTECTED]>
>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Jon Parise]

On Tue, Apr 24, 2001 at 12:26:34PM +0300, Zeev Suraski wrote:

> The race between world peace and PHP 4.0.5 is tightening by the minute :)
> Anyway, let's say Wednesday evening (GMT) would be the last time to put in 
> changes;  RC8 goes out then;  4.0.5 goes out on Monday, unless there are 
> serious show stoppers.

And I assume the 4.0.5 release will be based on the RC8 tag
(unless there's a strong reason otherwise, of course).

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Zeev Suraski]

Not necessarily;  Crash bugs can very often lead to security issues.  Of 
course, it's a clearer cut if it's in a situation which is very likely to 
happen.

Zeev


At 17:09 24/4/2001, Andi Gutmans wrote:
>At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote:
>>A reproducible crash bug in a mainstream module is a show stopper IMHO...
>
>I think you mean in a mainstream module and in a situation which has a 
>high chance of happening.
>Crash bugs which are 1 in a million don't necessarily need to be show 
>stoppers.
>
>Andi

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


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Andi Gutmans]

At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote:
>A reproducible crash bug in a mainstream module is a show stopper IMHO...

I think you mean in a mainstream module and in a situation which has a high 
chance of happening.
Crash bugs which are 1 in a million don't necessarily need to be show stoppers.

Andi


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Zeev Suraski]

A reproducible crash bug in a mainstream module is a show stopper IMHO...

Zeev

At 14:16 24/4/2001, Jani Taskinen wrote:
>On Tue, 24 Apr 2001, Zeev Suraski wrote:
>
> >At 12:03 24/4/2001, Sascha Schumann wrote:
> >>On Tue, 24 Apr 2001, Zeev Suraski wrote:
> >>
> >> > At 03:02 24/4/2001, Anil Madhavapeddy wrote:
> >> > >It a bit of a showstopper for pretty much all web-based mail clients
> >> > >like IMP - people have been reporting their logs being littered with
> >> > >segfaults for a while now actually.
> >> >
> >> > Ok then, merge it in, and looks like we'll have to have RC8 after all.
> >>
> >> There has been a simple API change in Apache 2.0 as well
> >> which I'd like to accomodate.
> >
> >The race between world peace and PHP 4.0.5 is tightening by the minute :)
> >Anyway, let's say Wednesday evening (GMT) would be the last time to put in
> >changes;  RC8 goes out then;  4.0.5 goes out on Monday, unless there are
> >serious show stoppers.
>
>Or someone else comes and says "this tiny change is really needed by XXX
>software users around the world.." ?
>
>I think this should end now. Release 4.0.5 now as is. And roll out 4.0.6RC1.
>Or on next monday we'll have RC9..
>
>--Jani

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


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Jani Taskinen]

On Tue, 24 Apr 2001, Zeev Suraski wrote:

>At 12:03 24/4/2001, Sascha Schumann wrote:
>>On Tue, 24 Apr 2001, Zeev Suraski wrote:
>>
>> > At 03:02 24/4/2001, Anil Madhavapeddy wrote:
>> > >It a bit of a showstopper for pretty much all web-based mail clients
>> > >like IMP - people have been reporting their logs being littered with
>> > >segfaults for a while now actually.
>> >
>> > Ok then, merge it in, and looks like we'll have to have RC8 after all.
>>
>> There has been a simple API change in Apache 2.0 as well
>> which I'd like to accomodate.
>
>The race between world peace and PHP 4.0.5 is tightening by the minute :)
>Anyway, let's say Wednesday evening (GMT) would be the last time to put in
>changes;  RC8 goes out then;  4.0.5 goes out on Monday, unless there are
>serious show stoppers.

Or someone else comes and says "this tiny change is really needed by XXX
software users around the world.." ?

I think this should end now. Release 4.0.5 now as is. And roll out 4.0.6RC1.
Or on next monday we'll have RC9..

--Jani



-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Zeev Suraski]

At 12:03 24/4/2001, Sascha Schumann wrote:
>On Tue, 24 Apr 2001, Zeev Suraski wrote:
>
> > At 03:02 24/4/2001, Anil Madhavapeddy wrote:
> > >It a bit of a showstopper for pretty much all web-based mail clients
> > >like IMP - people have been reporting their logs being littered with
> > >segfaults for a while now actually.
> >
> > Ok then, merge it in, and looks like we'll have to have RC8 after all.
>
> There has been a simple API change in Apache 2.0 as well
> which I'd like to accomodate.

The race between world peace and PHP 4.0.5 is tightening by the minute :)
Anyway, let's say Wednesday evening (GMT) would be the last time to put in 
changes;  RC8 goes out then;  4.0.5 goes out on Monday, unless there are 
serious show stoppers.

Zeev


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Sascha Schumann]

On Tue, 24 Apr 2001, Zeev Suraski wrote:

> At 03:02 24/4/2001, Anil Madhavapeddy wrote:
> >It a bit of a showstopper for pretty much all web-based mail clients
> >like IMP - people have been reporting their logs being littered with
> >segfaults for a while now actually.
>
> Ok then, merge it in, and looks like we'll have to have RC8 after all.

There has been a simple API change in Apache 2.0 as well
which I'd like to accomodate.

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


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Zeev Suraski]

At 03:02 24/4/2001, Anil Madhavapeddy wrote:
>It a bit of a showstopper for pretty much all web-based mail clients
>like IMP - people have been reporting their logs being littered with
>segfaults for a while now actually.

Ok then, merge it in, and looks like we'll have to have RC8 after all.

Zeev


-- 
PHP Development Mailing List 
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] 4.0.5: Merge Request

[Anil Madhavapeddy]

It a bit of a showstopper for pretty much all web-based mail clients
like IMP - people have been reporting their logs being littered with
segfaults for a while now actually.

Anil
- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Chuck Hagenbuch" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, April 24, 2001 12:39 AM
Subject: Re: [PHP-DEV] 4.0.5: Merge Request


> I'd like to get 4.0.5 today (Tuesday), so no new merges will make it
in...
> How bad is this bug?  If it's not a showstopper, the show should go
> on.  Chances are 4.0.6 will come out relatively soon after 4.0.5 does.
>
> Zeev
>
> At 01:20 24/4/2001, Chuck Hagenbuch wrote:
> >I'd like to merge the following patch:
>
>http://cvs.php.net/viewcvs.cgi/php4/ext/imap/php_imap.c.diff?r1=1.64&r2
=1.65
> >
> >... into 4.0.5. It's a very small fix that fixes a bug in imap_sort
which is
> >_very_ easy to trigger.
> >
> >Any objections?
> >
> >-chuck
> >
> >--
> >Charles Hagenbuch, <[EMAIL PROTECTED]>
> >
> >Taurus:
> >You will receive an urgent transmission from the Martian government
informing
> >you that Mars does not, in fact, need women, so please stop sending
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]
>
> --
> 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] 4.0.5: Merge Request

[Zeev Suraski]

I'd like to get 4.0.5 today (Tuesday), so no new merges will make it in...
How bad is this bug?  If it's not a showstopper, the show should go 
on.  Chances are 4.0.6 will come out relatively soon after 4.0.5 does.

Zeev

At 01:20 24/4/2001, Chuck Hagenbuch wrote:
>I'd like to merge the following patch:
>http://cvs.php.net/viewcvs.cgi/php4/ext/imap/php_imap.c.diff?r1=1.64&r2=1.65
>
>... into 4.0.5. It's a very small fix that fixes a bug in imap_sort which is
>_very_ easy to trigger.
>
>Any objections?
>
>-chuck
>
>--
>Charles Hagenbuch, <[EMAIL PROTECTED]>
>
>Taurus:
>You will receive an urgent transmission from the Martian government informing
>you that Mars does not, in fact, need women, so please stop sending them.
>
>--
>PHP Development Mailing List 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]