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?
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 http://www.php.net/
To
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
36 matches
Mail list logo
