Re: cvs: php4(PHP_4_0_5)/sapi/fastcgi

Some thoughts..... 1. Adding new/experimental extensions _can_ invisibly bug the rest of a build, if they require such nastiness as the recent pthread debugging. It's not only a minor configure issue when a built app breaks due to library issues, because extensions can be linked in conflicting ways. It does happen, it has happened.... in rather annoying, small ways (see mod_ssl vs. mysql client and -lpthread linking issues.). These bugs suck, but they do happen, because extensions are not ever totally isolated if they are running on the same system, and linking to something else. 2. A QA process works well when it has a fixed target. If it's a highly mobile target, every RC becomes an RC1. That means that RC2 is difficult, if not impossible, to pin down for the final release. 3. By the same token, changes between RC's often must be made... if RC1 has problems, it's semi-mobile anyways. One of the goals in the issue is to make it as immobile as possible. This will often require rulesets that seem odd. Those rulesets are there because they help to pin down bugs. As a mental example, imagine if bugs.php.net had no version information (If RC1 and RC 2 have different code, different bugs are possible, if not probable). Those rules generally forbid any new features or functions. 4. If people want the newest features, we have daily CVS snapshots for just that reason. QA'd, tested, release features and functionality, without surprises, can also be downloaded, in a different place. (If they _need_ fastcgi, there's nothing that prevents them from getting it, RC or not.... is there?) Several open-source workflows have adopted this, to the point where a QA'd, certified, "official" version is a sold item, but the wild-and-loose source is free. 5. Nobody wants to add something that may break PHP. However, anticipating all possible effects of one file on 2862 other files (as of 20010304) is a bit of a challenge, if not impossible for many mortals. I am not implying that the dev team is any less than infalliable gods, but QA mortals and demi-gods like to have more reassurance than "It will work, no problem". :-) 6. QA is not about making folks happy. It is bean-counting, line-checking, focused, pragmatic, work. It is making sure that line changes in file 1261 did not affect functionality in 2861 other files. Adding 120 lines makes it much more difficult. 7. That all being said, I'd be much happier if we could get into a "tighter" QA release loop. Say, one week per frozen RC. If we add anything, at all, it should be scheduled for another QA RC run. Perhaps much of this issue could be settled by making "dead" forks, where the RC forks have only RC bug fixes and/or releases. Everything else goes into the main source. My dos centavos, -Ronabop --2D426F70|759328624|00101101010000100110111101110000 Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not necessarily those of myself, my employers, or any of the other little voices in my head.