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

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

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.

hey man you have two options:

• you fill bug reports and attach patches to them (you said you have
  fixed them all). manpower is surely not an issue on our side. if
  something needs discussion, you can also join us on IRC.
• you shut up (i.e. stop posting on PHP mailing lists). I already
  have enough useless e-mails on my inbox every day.

Thanks,
Nuno

On 04.09.2007 21:48, BuildSmart wrote:

Unlike many developers who do this in their spare time, I have the
time, resources, energy and motivation to attack PHP with extreme
aggression.

Please stop here, right now.
No need to attack anything or anyone.
If you want your job (or life, 'cause for most of us job is a substantial part of life)
to become a little bit easier, you need to learn to communicate and to be a part of community.
Yes, it might not be that easy as it looks like from the first glance.
But if you continue to do what you're doing right now, you'll get into everybody's ignore list in couple of days.

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.

Believe it or not, but due to the nature of my job I've encountered
hundreds of issues and fixed/reported (or both) most of them.
And that did not cause a flamewar in the lists and did not involve any personal insults.

We really do appreciate your contributions, but it's just impossible to work
with someone who ignores all the rules and does not respect the others.

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.

Please, calm down, no need to worry so much.
During the previous several years I did it almost every week, for MacOS, Linux, AIX, Solaris and other platforms.
Yes, and universal binaries too. And they work fine, yes, thanks for asking.
So what?

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.

This issue was discussed on the list a couple of weeks ago, search the archives.
Btw, thanks for reminding, I need to commit the patch fixing it.

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

It's funny to hear such things from someone definitely familiar with operating systems..

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.

That's really nice.
"I fixed something nasty, but I won't show you. Find it yourself, you stupid."
Way to go! Really helpful.

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.

Sam Ruby wrote really nice blog entry on this topic:
http://intertwingly.net/blog/2007/07/17/Popular-Sovereignty

If you want PHP dev to support your platform properly - become one of them and do it.
It's easy.

--
Wbr,
Antony Dovgal

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.

I think you need not to worry about swamping developers. If all of the
issues are real bugs, the developers would find time - now or in the
future - to fix them. Even if they do not - either because nobody
considered it important or some other reason - the issue would still be
known and waiting for somebody to fix it, eventually. That's the power
of open source development model.
I understand that having to encounter a lot of bugs can be frustrating,
and it can happen if you venture to do something that not many have done
before. The best way to deal with it is to contribute a little amount of
your time on filing bug reports, thus enabling the community to work
with you and contribute back.

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.

Of course, nobody could demand from you to contribute your fixes or your
information back - but it is a good citizenship if you do.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

Dear Mr. BuildSmart

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.

if you want your fixes applied you need to get them reviewed for
now, and the proper workflow to get that done is to file bug reports
with patches attached, not posting them in the mailing list
(and especially not putting them in only rather late in a thread).

Posting patches to the mailing list right away sort of works, too,
but in the long run it produces more work for everyone, not less.

You don't have to agree with this, but you have to accept the
established workflow nonetheless ... or accept not being taken
serious (which your insistence of not putting your real name
into your "From:" field already substantially contributes to ...)

--
Hartmut Holzgraefe, Principal Support Engineer
.
Discover new MySQL Monitoring & Advisory features at:
http://www.mysql.com/products/enterprise/whats_new.html

Hauptsitz: MySQL GmbH, Dachauer Str.37, 80335 München
Geschäftsführer: Kaj Arnö - HRB München 162140