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: [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 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.
--
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]
