Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daleenterprise.com from 67.78.11.229 cause and error)
In-Reply-To: <46DD9EE7.6010206@gmail.com>
References: <20CECB37-7174-498C-85EA-A862923E594D@daleenterprise.com> <1188809931.3317.0.camel@localhost.localdomain> <C0C21D32-D496-49E1-92E0-A860E866CAF4@daleenterprise.com> <46DC0FFC.9040403@mysql.com> <4AA18585-8F96-4A6E-A990-E5FAD0DECA7E@daleenterprise.com> <46DC5EB6.8020805@mysql.com> <925E216E-7B66-4D68-956B-042C1422FE90@daleenterprise.com> <fe05d1540709040224l5c2251b5p3e45db9cab77c498@mail.gmail.com> <0C276E60-3C18-4A4A-943A-DC58A05FD557@daleenterprise.com> <46DD575F.6070004@mysql.com> <D861C785-6718-475B-9910-8A5B94112C4B@daleenterprise.com> <46DD9EE7.6010206@gmail.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <F3946A80-7368-41C2-BF5D-CC6B5E0463B1@daleenterprise.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Tue, 4 Sep 2007 16:39:33 -0400
To: Stut <stuttle@gmail.com>
MTA-Interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.1.0 at daleenterprise.com
Subject: Re: [PHP-DEV] buildconf and the generated configure script for PHP6 is faulty [the fix].
From: buildsmart@daleenterprise.com (BuildSmart)

-----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-----