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.
-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)
iD8DBQFG3Zps0hzWbkf0eKgRAvCuAKCCUJmTvX7jdrScyEAsuJtPRMmtYgCfT8Cq
QDX4C2DLiHcGbDF2nijHnk8=
=op9E
-----END PGP SIGNATURE-----
--PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
