-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 4, 2007, at 09:02:23, Hartmut Holzgraefe wrote:
Dear Mr BuildSmart
BuildSmart wrote:
SInce I didn't consider it a bug but rather a minor error of
importance,
just out of curiosity: how do you define "bug" if not as "any error"?
I thought it would best be handled by making the maintainers aware
of the issue since the fix is relatively simple and provided to
avoid the filing of bug reports which would have occurred.
this is wrong in several ways:
- your original posting did not include the actual fix but
only what should change in the generated configure file
the actual fix was only in your mail of 12:10 today.
giving you the benefit of the doubt i'd assume for now
that it was attached to the original message, too, but
got stripped, this would not have happened with a bug
report though
- the bug database is not only a todo list, it is also
a repository of bugs fixed in the past. e.g. have you
noticed the duplicate detection when filing a bug?
with a bug fixed out of band without involving the
bugs db duplicate detection can't kick in on new bug
reports
- changelog entries usually refer to a bug number,
having them point to a mail archive instead would
be inconsistant and so bad
- same for commit messages ... add to this that it is
easy to refer to a bug number but way less so to
refer to a distinct email
So working around the bug system is not a shortcut,
it actually generates *more* work in the long run.
The bug system is there to be *used*, not to be
circumvented.
If you had submitted your finding as a bug report
with proper how-to-reproduce instructions (which
your original message did not have, what you wrote
there was way to vague) and also with your patch
to ext/standard/config.m4 things would probably
been handled just fine already. Look what mess you
caused instead ... :(
My original post did very well outline how to reproduce the issue
because the entire terminal session was provided,
mess???
Unlike many developers who do this in their spare time, I have the
time, resources, energy and motivation to attack PHP with extreme
aggression.
I'm paid a minimum of $750.00 USD to generate binaries of PHP, yes
people pay me because they are tired of the issues with using
packages like the entropy PHP (nothing personal against Mark, I know
him) so for the most part, I spend an average of 8 hours a day
building various version of PHP and the required dependancy software.
Due to the nature of my work, I have encountered just about every
imaginable bug in the build process, if I were to submit bug reports
on each and every issue encountered, the number alone would swamp the
developers who spend their time validating and substantiating the
reported bugs because I am not your average yogi bear.
A supply of various hardware is abundantly on hand, I build for 2
different architectures so I see problems that only affect one
architecture and not the other and I can generate a dual architecture
build in a single pass on a single machine so spending the time
building on two different machines and then manually combining the
binaries or scripting the process isn't required.
If someone here can generate the same type of build that works I
would be very impressed.
If you think I'm wrong or talking out of my @$$, try building PHP for
dual architecture in a single pass with date enabled and then run
this build on a ppc and an intel machine and tell me that the php_info
() function doesn't fail on one of the architectures or that it
doesn't segfault when using the date functions.
I wont even go into the dedication issue of providing windows
binaries but no binaries for other platforms that is a constant user
gripe that windows is favored which is another reason that posting
the extensive bug list would further tarnish the current image which
isn't to shiny to begin with.
I'm not interested in filing a minimum of 100 bug reports when you
don't have the manpower to process them, I've resolved most of them
already (at least the ones related to the php base) and any that I
haven't I've noted as "Broken - DNU" so I don't pass anything
unstable on to my clients.
So now that you see I'm talking about considerably more than a
handful of bugs you should be able to grasp why I don't report them
or wish to spend the considerable amount of time required in
reporting all of them when it would take forever for them to be
processed and to have users hit the PHP site and see the large list
would only create further animosity by a quickly growing group of
hardware owners who already believe that their platform isn't being
properly supported by the PHP dev group as it is.
--
Hartmut Holzgraefe, Principal Support Engineer
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG3Zps0hzWbkf0eKgRAvCuAKCCUJmTvX7jdrScyEAsuJtPRMmtYgCfT8Cq
QDX4C2DLiHcGbDF2nijHnk8=
=op9E
-----END PGP SIGNATURE-----
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
