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

[Cynic]

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 ? It starts with a B and it's all a Bug Story...

How about Big Drum? :)


[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 
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: 4.0.5: Merge Request

[Hellekin O. Wolf]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: 4.0.5: Merge Request

[James Moore]

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: 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 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: 4.0.5: Merge Request

[Rasmus Lerdorf]

> 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 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] RE: 4.0.5: Merge Request

[Stephen van Egmond]

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-long affairs.  Start Friday, end
Monday morning.

> But I'm really not
> in favor of adding more process.

It's more of a social process than an explicit development process. 
The only extra "process" is a new severity level in their bug system,
to indicate that bug must be resolved for release to occur.  It's not
zero-defects, it's zero release-critical defects.

People just yell "bug party!" maybe invite some friends over and start
hacking.  Everyone in an IRC channel.

> Personally, I've never seen adding steps to a
> development process actually help development. It seems like instead of voting,
> maybe QA people (as well as developers) should have ability to set priorities
> on bugs (although these are arguably very subject to perspective).

The mozilla project allows members of the public to "vote for" a bug to
indicate that it's bad and annoying to them.  This can be used as input
to determining that a bug is RC.

Along other lines, we could play platform favourites and say that
anything that reproducibly crashes an x86, ppc, or alpha system is RC.

It's all squishy heuristics, and until we start playing with it we'll
never know what works.


-- 
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] RE: 4.0.5: Merge Request

[Phil Driscoll]

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 that the bug report gets posted
to the dev list with 'showstopper' status should be enough to alert people
to either fix it, or argue for its demotion to a less severe status. The
rule should be that showstoppers are never allowed in a release.

Prior to the bug database getting this feature, the list can be manually
maintained on the qa list.

A strongly agree with Liz that we MUST become strict about no new features
going into the release branch after RC1. Maybe this would be helped by a
regular RC cycle - maybe once every two months. Then everyone will know when
RC1 is due and if they want features in it, then they know what date they
have to hit to get it there. And if they miss the date, they know it's only
two months before it will get into a release.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
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] RE: 4.0.5: Merge Request

[John Donagher]

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 should be treated the same way.
> 

I think one of the key benefits of open source is the flexibility of the
development process. The software changes to fit the changing needs of its
users (many of which, in open source, are the developers); it is not beholden
to strategic planning and static project roadmaps. Keeping this flexibility
intact is a great contributor to PHP's growth and continued improvement. 

> For 4.0.6 for example we should be aiming to get rid of all recreatable and
> rated "very likely to be found" bugs, with bugs ranking down to "obscure
> things unlikely to be found by the masses" - and weight them accordingly, so,
> the more likely it is to be found and annoy someone, the more we'd like to fix
> it before release.  So, to your list, why not just add a voting for the QA
> people to vote how likely they feel it would come up/how much they would hope
> to see it in the next produce from the dev team?
> 

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). But I'm really not
in favor of adding more process. Personally, I've never seen adding steps to a
development process actually help development. It seems like instead of voting,
maybe QA people (as well as developers) should have ability to set priorities
on bugs (although these are arguably very subject to perspective).

-- 

John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


-- 
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] RE: 4.0.5: Merge Request

[Rasmus Lerdorf]

> 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 rate stuff isn't likely to be useful.  The signal to
noise ratio of public votes like that is bad.  For example, if Chuck says
there is a serious bug in the IMAP library (like he did) then I don't care
if 500 people rate that issue as insignificant.  I'd trust his opinion.

> 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 should be treated the same way.

For us, major revisions (V5) are for entire rewrites.  V 4.1 would be for
significant new functionality and the dot-releases are for bug fixes and
moderate functionality increases.  I don't think there is any need to
change that.

-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]

[PHP-DEV] RE: 4.0.5: Merge Request

[Liz]

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

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 should be treated the same way.

For 4.0.6 for example we should be aiming to get rid of all recreatable and
rated "very likely to be found" bugs, with bugs ranking down to "obscure
things unlikely to be found by the masses" - and weight them accordingly, so,
the more likely it is to be found and annoy someone, the more we'd like to fix
it before release.  So, to your list, why not just add a voting for the QA
people to vote how likely they feel it would come up/how much they would hope
to see it in the next produce from the dev team?

Is that a reasonable idea?


-- 
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] RE: 4.0.5: Merge Request

[Boian Bonev]

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 security risk and are just a
new/unused feature that does not work as expected. it IS ok to release with
such a segfault. an example:

bbonev@orange:~$ echo "" | php -a
Interactive mode enabled

X-Powered-By: PHP/4.0.5RC6
Content-type: text/html

Segmentation fault

see bug id 8621

i think commonsense shall be used to judge what is showstopper and what is
not :)
this one definitely is not

b.


-- 
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: 4.0.5: Merge Request

[Liz]

> 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?

[snip]

I agree, no version will ever ever be 100% perfect.  There will always be some
quirk, or some feature which isnt always right.  As you said, QA is to test it
and make sure we've nailed down ALL the problems before it goes out, and those
that can be fixed are. Those that cant in a reasonable amount of time, or
arent deemed a necessary fix or common problem get left till next time.

However, as you say, there are quite a few problems which STILL dont work.  I
appear to have closed 1 bug which was a seg fault, as I tested it with the CVS
release of the time, but now again, it appears to have broken. So, I need to
go back and reopen it. I can recreate it on 2 versions of linux, so, it
suggests its something bad. And just to check, no it still seg faults.. it
always has, except for 1 version of the CVS which meant it got closed.

What I think we need to do is chat with the developers and come up an
agreement

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.
2. When we hit say RC1 all the features we want to see in the new version are
in, no one ones are added, only bugs fixed.
3. If a developer is unhappy/unable/unwilling/not able to solve problems
within their module for whatever reason, a second person who is able needs to
be sought.

The QA team maybe need to vote on a bug and say if they could recreate it, if
no one can recreate it a bug is perhaps less serious than one everyone can
recreate and it gets a weighting flag accordingly..

Another idea would be to list supposedly fixed bugs in the release, and any
new features..

Am I mad? this is how our QA team worked..  It does take give and take on both
sides as if QA were right, no product would ever leave, but if most developers
had their way (I speak as one as well) we'd rather play with new bits or not
worry if we dont see it it cant be so important..

We arent children, we should be able to sort it out.


-- 
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]