Re: Re: 4.0.6
| From: | Zeev Suraski | Date: | Thu, 03 May 2001 09:25:50 +0000 |
| Subject: | Re: Re: 4.0.6 | ||
| References: | 1 | Groups: | php.dev php.qa |
| Request: | Send a blank email to php-dev+get-53548@lists.php.net to get a copy of this message | ||
At 12:12 3/5/2001, Jani Taskinen wrote:
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'.<quote>
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.. </quote> ???
Nobody said anything about following 'nazi-like' strict rules either. Where are you reading this? I would like to see that email too.Nazi-like was my way of describing it. Having an arbitrary group of people decide about what gets in and what doesn't, with "no exceptions", etc., makes no sense in an opensource project.
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?It doesn't say anything anywhere. There are certain characteristics in opensource projects, which are obvious results of the way things work in such projects. One of them is that there aren't strict rules, but guidelines (the difference between negative motivation and positive motivation). Remember people work on their free time, if you start 'following orders', you take away the fun.
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.I won't get into that argument again. You're more than invited to look it up in the archives and see the huge difference, and why I think it's so ok that it should actually become a part of the guidelines. Zeev