[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:

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

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