-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sep 4, 2007, at 14:07:35, Stut wrote:
Hello Dale,
I'm not experienced enough to comment on most of what you said, but
not reporting bugs in a piece of software because you're worried
that 1) the developers won't be able to deal with the volume and 2)
you're worried about damaging the reputation of said software has
to be the most idiotic attitude I've ever come across.
The complaints over the 4 or 5 I have mentioned on the list has borne
the remarks that I swamp the list with the reports, how it would be
if I dumped a couple hundred?
To disregard the perception of the PHP software and it's developers
is a stoic thought concept, since you have no issues accepting the
concept that the majority of end users believe that the PHP software
is a collection of cruft managed by a group of pompous programmers
doesn't mean that the other developers share in this concept, image
in a web-related world has value whether you give it any or not so
airing everything isn't always the best policy.
Rather than contribute to any negative thoughts and impressions that
would be attained by submitting countless bug reports that would take
months if not years to process or most likely just be ignored, I
believe it's best to refrain from such submission unless it's
absolutely critical.
This is going absolutely nowhere, I'm dropping out of this discussion
to avoid retaliations due to bruised egos.
Let it die here.
-Stut
BuildSmart wrote:
-----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)
iD8DBQFG3cKG0hzWbkf0eKgRAjojAJ0YFSWSUCjDOK1fW1i7S00IAMho1QCfWuk/
HsWZYVM16GS0cBi+tBNaw4k=
=iaKb
-----END PGP SIGNATURE-----
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
