[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: 4.0.5: Merge Request

At 10:18 26.4. 2001, Hellekin O. Wolf wrote the following: -- >At 19:06 25/04/2001 +0100, James Moore wrote: >>Its doesnt at all :) We are using it as a temporary codename until we can >>think of a better one. >> >>- James > >*** Brazil

Re: [PHP-DEV] RE: 4.0.5: Merge Request

At 19:06 25/04/2001 +0100, James Moore wrote: >Its doesnt at all :) We are using it as a temporary codename until we can >think of a better one. > >- James *** Brazil ? It starts with a B and it's all a Bug Story... -- PHP Development Mailing List To unsubscribe, e-mail:

[PHP-DEV] RE: 4.0.5: Merge Request

Its doesnt at all :) We are using it as a temporary codename until we can think of a better one. - James > -Original Message- > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] > Sent: 25 April 2001 18:42 > To: James Moore > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: 4.0.5: M

[PHP-DEV] Re: 4.0.5: Merge Request

> you should subscribe to the [EMAIL PROTECTED] list where discussion > about a new bug system is occuring. I hope the name of this mailing list does not imply that you are at all considering actually using Jitterbug. I know this code and we really don't want to use it. -Rasmus -- PHP Develo

Re: [PHP-DEV] RE: 4.0.5: Merge Request

John Donagher ([EMAIL PROTECTED]) wrote: > Someone mentioned the idea of bug-squashing parties; I think that's a great > idea, although since the project's developers are all over the world it may be > a little tricky to organize (I'm not fixing bugs at 10AM). Debian's bug parties are weekend-lo

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: 4.0.5: Merge Request

No new ideas here, just clarification of what I think we should do with the current technology available. As far as I remember, someone is rewriting the bug db (or maybe I was dreaming?). If so, then a new 'importance' field can be added to rank the bug as showstopper, important etc. The fact tha

Re: [PHP-DEV] RE: 4.0.5: Merge Request

On Wed, 25 Apr 2001, Liz wrote: [snip] > > As a major version say v5 would have lots of new features, but 4.0.6 for > example mainly bug killings with maybe some feature improvements, 4.1 would > contain bug killings (of course) but some new features but nothing earth > shattering, and the bugs

Re: [PHP-DEV] RE: 4.0.5: Merge Request

> OK, my opinion would be to put a copy of the currently known bugs with the RC > source. To give people a local (ie offline) list to look at. Then, why not > use a ranking scheme, people rate how much they feel a specific bug needs > fixing before the new version.. ie Having people vote or rat

[PHP-DEV] RE: 4.0.5: Merge Request

> 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? OK, my opinion would be to put a copy of t

Re: [PHP-DEV] RE: 4.0.5: Merge Request

hi, > Maybe something like this > > 1. Any problems which result in seg faults/gpfs are show stoppers, code doesnt > go out till its fixed, or feature is removed till we can fix it. this is not correct (in general :) - there are segfaults in experimental stuff that do not imply exploits, are no

[PHP-DEV] RE: 4.0.5: Merge Request

> 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