[PHP-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Zeev Suraski

And you expect us to give you that power? :)
Seriously, PHP isn't going to start following Nazi-like strict rules.  We 
shouldn't get into jurisdictions and stuff like that because they're 
endless discussions with no point.  In an opensource project you can set 
guidelines, not laws, and we should work to improve those guidelines as we 
gather experience.

I still think that the FastCGI thingy was fine, by the way.  It's modifying 
existing code in the last minute that causes trouble.

Zeev

At 04:54 3/5/2001, Jani Taskinen wrote:
On Wed, 2 May 2001, Steve Langasek wrote:

 Give the QA team that power.  Let the release branch be reserved exclusively
 for bugfixes, and give the QA team control over what gets committed to the
 branch.  This is the only way to make headway against bugs.

Amen. There can't be _ANY_ exceptions to this. Not even Sascha or ANYBODY
else. Including Zeev/Andi/Rasmus. Just thinking of that FastCGI thingie..

--Jani



--
PHP Quality Assurance 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]




Re: [PHP-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Zeev Suraski wrote:

And you expect us to give you that power? :)

Did I suggest that? I didn't. I was referring only to
the rest of that piece of text, not the part about 'giving power'.

Seriously, PHP isn't going to start following Nazi-like strict rules.  We
shouldn't get into jurisdictions and stuff like that because they're
endless discussions with no point.  In an opensource project you can set
guidelines, not laws, and we should work to improve those guidelines as we
gather experience.

Nobody said anything about following 'nazi-like' strict rules either.
Where are you reading this? I would like to see that email too.

Where can I find these nazi-like strict rules to what kind of procedures
opensource projects should have? Where does it say that an opensource
project can't have strict rules on release cycle?

I still think that the FastCGI thingy was fine, by the way.  It's modifying
existing code in the last minute that causes trouble.

Adding any new code into the configure system is a possible cause for
trouble. As is modifying existing code too.

--Jani


Zeev

At 04:54 3/5/2001, Jani Taskinen wrote:
On Wed, 2 May 2001, Steve Langasek wrote:

 Give the QA team that power.  Let the release branch be reserved exclusively
 for bugfixes, and give the QA team control over what gets committed to the
 branch.  This is the only way to make headway against bugs.

Amen. There can't be _ANY_ exceptions to this. Not even Sascha or ANYBODY
else. Including Zeev/Andi/Rasmus. Just thinking of that FastCGI thingie..

--Jani



--
PHP Quality Assurance 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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread derick

On Thu, 3 May 2001, Sascha Schumann wrote:

 On Thu, 3 May 2001, Jani Taskinen wrote:

  Amen. There can't be _ANY_ exceptions to this. Not even Sascha or ANYBODY
  else. Including Zeev/Andi/Rasmus. Just thinking of that FastCGI thingie..

 Funny that you mention my name as the first one in the list.
 I've been known for arguing for completely shutting down
 commit access to release branches and to give absolute
 control to the release master who is then responsible for
 applying only well-tested bug fixes.  Unfortunately, this
 conservative approach is not too popular around here.

May be not popular, but I think this is the best way to go. But I think
that release master should exists of not only one person, but a few
PHP-QA members.

Derick Rethans

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


-- 
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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Andi Gutmans

At 11:08 AM 5/3/2001 +0200, Sascha Schumann wrote:
On Thu, 3 May 2001, Jani Taskinen wrote:

  On Wed, 2 May 2001, Steve Langasek wrote:
 
  Give the QA team that power.  Let the release branch be reserved 
 exclusively
  for bugfixes, and give the QA team control over what gets committed to the
  branch.  This is the only way to make headway against bugs.
 
  Amen. There can't be _ANY_ exceptions to this. Not even Sascha or ANYBODY
  else. Including Zeev/Andi/Rasmus. Just thinking of that FastCGI thingie..

 Funny that you mention my name as the first one in the list.
 I've been known for arguing for completely shutting down
 commit access to release branches and to give absolute
 control to the release master who is then responsible for
 applying only well-tested bug fixes.  Unfortunately, this
 conservative approach is not too popular around here.

If I'm the release master I don't mind :) hehe

Andi


-- 
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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Cynic

Zeev, 

do you think ASF is a Nazi-like group? I don't think so.
Nor do I witness endless discussions caused by the fact that
the Apache release cycle is far (in a galaxy far, far away.. :)
stricter than the PHP one.

4.0.5 took very long to release, and it seems like it could 
have been released a month ago - pl1 is inevitable anyway.

On the other hand, I must say that the win32 version of PHP 
these days is great. When I recall the days 6-8 months ago,
it's incredible how much has been achieved.

One more thing: unless I'm mistaken, vast majority of people 
who have raised their voices has voted for tighter rules.
I'm of the same opinion. Without an effective way to impose 
their judgement, the QA team is just a joke.

At 10:50 3.5. 2001, Zeev Suraski wrote the following:
-- 
And you expect us to give you that power? :)
Seriously, PHP isn't going to start following Nazi-like strict rules.  We shouldn't 
get into jurisdictions and stuff like that because they're endless discussions with 
no point.  In an opensource project you can set guidelines, not laws, and we should 
work to improve those guidelines as we gather experience.

I still think that the FastCGI thingy was fine, by the way.  It's modifying existing 
code in the last minute that causes trouble.

Zeev

At 04:54 3/5/2001, Jani Taskinen wrote:
On Wed, 2 May 2001, Steve Langasek wrote:

Give the QA team that power.  Let the release branch be reserved exclusively
for bugfixes, and give the QA team control over what gets committed to the
branch.  This is the only way to make headway against bugs.

Amen. There can't be _ANY_ exceptions to this. Not even Sascha or ANYBODY
else. Including Zeev/Andi/Rasmus. Just thinking of that FastCGI thingie..

--Jani



--
PHP Quality Assurance 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 Quality Assurance 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]
--end of quote-- 


[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 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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Cynic

At 12:48 3.5. 2001, Andi Gutmans wrote the following:
-- 
At 12:47 PM 5/3/2001 +0200, Cynic wrote:
Zeev,

do you think ASF is a Nazi-like group? I don't think so.
Nor do I witness endless discussions caused by the fact that
the Apache release cycle is far (in a galaxy far, far away.. :)
stricter than the PHP one.

Is it? I'm not that sure. They also release with known bugs although I admit to not 
knowing their exact release cycle so I won't comment more on this :) By the way, in 
Zeev's not very successful way of using that N word what he meant was a dictatorship 
that makes binary decisions about everyone else. That's all he meant IMO.

Well, AFAICT only a limited group of people can commit, and 
whoever (including the commiters) has a patch, it's proposed,
and discussed. That means nothing is committed without peer 
review. I think this qualifies as far stricter. :)

4.0.5 took very long to release, and it seems like it could
have been released a month ago - pl1 is inevitable anyway.

I don't see a pl1 happening. We will go right to 4.0.6.

If that happens soon... Labels are just labels. :)

On the other hand, I must say that the win32 version of PHP
these days is great. When I recall the days 6-8 months ago,
it's incredible how much has been achieved.

One more thing: unless I'm mistaken, vast majority of people
who have raised their voices has voted for tighter rules.
I'm of the same opinion. Without an effective way to impose
their judgement, the QA team is just a joke.

(...)

In any case, thank god we don't have communication problems so I think everyone's 
voice will be heard when patches are merged into the release branch.
Anyway, why are we continuing to waste time on this instead of fixing bugs and 
emptying the bugs database.
4.0.5 was pretty fine and we'll tighten things for 4.0.6. I'm sure that after this 
whole Email exchange more people will be watching the release branch and more people 
will be shouting STOP. And they will be heard!
It'll work out OK. Don't worry about it.

So in the end, this wasn't a waste of time.

Ok, just from memory, at least these people are shouting 
no new features in the release branch (in no particular order): 

James Moore, Zak Greant, Jani Taskinen, Sascha Schumann, Derick 
Rethans, Steve Langasek, and me. Are we heard? :)

Don't get me wrong, things are getting better, but they wouldn't 
be without being talked about. That is, I'm not complaining or 
something.


[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 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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Jani Taskinen

On Thu, 3 May 2001, Andi Gutmans wrote:

At 12:47 PM 5/3/2001 +0200, Cynic wrote:
Is it? I'm not that sure. They also release with known bugs although I
admit to not knowing their exact release cycle so I won't comment more on

Ehem. We release with known bugs too but we don't tell it to anyone.. :)
(of course people can check the bug database..)

this :) By the way, in Zeev's not very successful way of using that N word
what he meant was a dictatorship that makes binary decisions about everyone
else. That's all he meant IMO.

I understood what he meant. Still, I don't think it's a bad idea to have
some kind of committee who decides whether a release is ready to be
released or not. Committee of like.. 10 persons could handle it better
than the current situation where there are 2 persons who decide on
releases.. you and Zeev. Now you guys wait an undefined amount of
time for feedback from QA and if you don't get it you seem to assume
everything is ok. Anyway. I might have misinterpreted this behaviour
of yours but that's how I see it. When we have 10 dedicated individuals
who represent the rest, they discuss whether a release is ok or not.
Vote about it or something. The current situation is horrible as nobody
knows the actual status of testing. My point is that the release should
be decided democraticly but still within limited number of people.

But if having any kind of ORDER here is so hard for some people, we
can forget this and continue with this x.x.x, x.x.xpl1/2/3, x.x.x,
x.x.xpl1/2/3 scheme..


CRAZY IDEA
Maybe we should have something like the terrorist cells?
ie. groups of 3 persons who know only about the one above them?

   X
 __|_
/\
   a  b
 / | \   / \
c (d) e e   g


and so on. Where X is the 'release master'.
How this works:

QA people c,d report to a that they have tested RC and it's ok.
A reports to X ok. A only reports IF he get OK from both c and d.
Same goes for B who only reports to X if he/she gets OK from e / f.

Then and only then X decides on release when he get's ok from both
A and B. There could also be more people on each cell. Like 3-5.

This is just a wild idea. Ignore if it's too wild. :)
I might have read too many spy books..but this could be effective..
We could have our 'cells' and every cell 'leader' recruits his/hers
testers.. who could then do the same too..and cell would be active
only if it has enough members..:)
/CRAZY IDEA

4.0.5 took very long to release, and it seems like it could
have been released a month ago - pl1 is inevitable anyway.
I don't see a pl1 happening. We will go right to 4.0.6.

Why would we need a pl? As there really isn't anything that
broken which would need it? (nothing that broken that wasn't
broken before)

I don't think that the QA team is a joke just because they can't
necessarily pull the plug on a release. Don't forget that a lot of the QA

Yes it is. As long as there is less than 5 persons who can decide
on this, QA is a joke.

Anyway, why are we continuing to waste time on this instead of fixing bugs
and emptying the bugs database.

At last he gets to the point! :)

4.0.5 was pretty fine and we'll tighten things for 4.0.6. I'm sure that
after this whole Email exchange more people will be watching the release
branch and more people will be shouting STOP. And they will be heard!
It'll work out OK. Don't worry about it.

PHP 4.0.5-Herzleid, PHP 4.0.6-Herzanfall..

--Jani



-- 
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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Zeev Suraski

At 13:47 3/5/2001, Cynic wrote:
Zeev,

do you think ASF is a Nazi-like group? I don't think so.
Nor do I witness endless discussions caused by the fact that
the Apache release cycle is far (in a galaxy far, far away.. :)
stricter than the PHP one.

I was talking about the ruleset and the way to follow them.  I'm didn't 
refer to any person or group with that adjective.

With all due respect to Apache, almost nothing is similar between the two 
projects, so the kind of rules they have there don't necessarily (and 
probably just don't) fit PHP.

4.0.5 took very long to release, and it seems like it could
have been released a month ago - pl1 is inevitable anyway.

It's inevitable enough for it not to exist;  I don't see any reason for 
pl1.  I think that the quality of 4.0.5 today is better than that of 4.0.5 
a month ago, except for this COM bug (we should keep in mind that the 
severity of a bug in this module is not that high, so there's no need to 
get concerned about it).

One more thing: unless I'm mistaken, vast majority of people
who have raised their voices has voted for tighter rules.
I'm of the same opinion. Without an effective way to impose
their judgement, the QA team is just a joke.

It's not a joke since it works.  I've only seen a couple of people even 
participating in this discussion, so 'vast majority' is meaningless.

Zeev


-- 
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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-03 Thread Zak Greant

Jani wrote:
 CRAZY IDEA
 Maybe we should have something like the terrorist cells?
 ie. groups of 3 persons who know only about the one above them?

X
  __|_
 /\
a  b
  / | \   / \
 c (d) e e   g

[...]
 /CRAZY IDEA

Wow this sounds like one of my ideas Jani.  :)

All we need now are some phpqat_tree_balance, phpqat_tree_...
functions and we are good to go! ;)

Seriously, IMO, this would be something fun to test off list
in one of the lags between a RC. We might learn something
neat and we might come up with a bunch of useless but
wickedly funny TLAs. :)

 4.0.5 took very long to release, and it seems like it could
 have been released a month ago - pl1 is inevitable anyway.
 I don't see a pl1 happening. We will go right to 4.0.6.

 Why would we need a pl? As there really isn't anything that
 broken which would need it? (nothing that broken that wasn't
 broken before)

 I don't think that the QA team is a joke just because they can't
 necessarily pull the plug on a release. Don't forget that a lot of the QA

 Yes it is. As long as there is less than 5 persons who can decide
 on this, QA is a joke.

 Anyway, why are we continuing to waste time on this instead of fixing
bugs
 and emptying the bugs database.

 At last he gets to the point! :)


After taking the time to really think about the current state
of the QA process, I think that we are doing just fine.

Our current process is better than the old process (aka none)

Now, each of us is smart enough to be able to single-handedly
rework the process into a perfect shining vision of how
QA should run. ;)  However, as a group, we have to be
moderate - or perhaps to rephrase that, we can't ramrod
changes past Zeev. ;)

Those of us who want to improve the process can do so by
watching the areas that matter to us.

I want to keep unneeded changes out of the RC process.
My opinion on RCs is like my mother's opinion on dinner:

Don't heap up your plate so much, you can always
go back for seconds.

So, I should watch CVS and squeal when anything non
bug related comes down the pipe.

If I do this regularly, I would guess that I would
have a much greater effect than any written set
of strict guidelines.

I think that if each of us takes a healthy interest
in the areas that matter to us and works to help
handle the relevant part of the process, we will find
that the process smooths out.

Take a look at who has made the most difference in how
we do things - it is not the people who make policies
for other people to follow.  It is the people who do
the work and in doing so, establish how others should
do it.

--zak


-- 
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-DEV] Re: [PHP-QA] Re: 4.0.6

2001-05-02 Thread Jani Taskinen

On Wed, 2 May 2001, Steve Langasek wrote:

Give the QA team that power.  Let the release branch be reserved exclusively
for bugfixes, and give the QA team control over what gets committed to the
branch.  This is the only way to make headway against bugs.

Amen. There can't be _ANY_ exceptions to this. Not even Sascha or ANYBODY
else. Including Zeev/Andi/Rasmus. Just thinking of that FastCGI thingie..

--Jani



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