-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'd like to work on resolving as many of the bugs as possible in the
shortest amount of time because there are not enough PHP developers
to go around validating and fixing every reported bug, this means
that the person assigned many of the bugs has his workload reduced
because he only has to substantiate the solution.
SInce I didn't consider it a bug but rather a minor error of
importance, 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.
For example, several complaints regarding MySQL and PHP and Mac OS X
have resulted in the filing of bug reports over an extended period of
time (since mysql.org has been providing binaries for Mac OS X) and
the issue never really documented or resolved, now this bug can be
entirely ignored because I took the time to validate the complaint
and bring to light the true fault (which I already knew from previous
experience with their packaged software) so now it should be openly
documented to avoid any more false filing on this bug.
If you prefer all matters to be handled by the respective bug report
venues that isn't a problem, I can collect all of the issues
regardless of their importance and file them and let the respective
assignee determine what is important and determine the appropriate
fix because my time would then be consumed by the filing of bug
reports with little time to spend substantiating and providing a fix,
however I feel that it may overwhelm the respective assignee due to
the shear number of issues and I was thinking that by weeding through
the simple fixes and providing the solution, the whole bug process
and a lot of user related complaints could be dramatically reduced by
prevention alone.
Further more, you could have played on my strengths by assigning me
the Mac OS X related bugs to substantiate and provide solutions for
those I can because I am fluent in this environment and the amount of
time required would more than likely be minimal but that looks like a
thought that wasn't considered by anyone.
Actually, I'll simplify matters even more and save my time, I wont
file any bug reports or provide any solutions, I'll leave that to the
end user to file a report after release that gets ignored because he
isn't technically inclined enough to write a proper report that
includes enough instructions, details or a potential solution as it
gets dragged out over an extended period of time because there isn't
enough personnel to go around.
Since all issues, even in betas and pre-release are to be considered
bugs and should be filed as bugs, I can now see why the PHP wheels
turn so slowly, sorry for wasting your time in an effort to assist
and expedite matters by trying to free the developers to more
important issues like software development rather than chasing bugs.
- -- Dale
On Sep 4, 2007, at 05:24:13, Pierre wrote:
Hi Dale,
I'm not sure I was clear enough in my last four replies. We have two
important issues tracker (for your needs):
http://bugs.php.net for all you can have in php releases or snaps
http://pecl.php.net for all PECL packages
http://pear.php.net for all PEAR packages (pear installer included)
All patches, bugs report and feature requests should be posted in one
of them. They can be discussed on the respective mailing list but
having the reports in these tools is the _only_ safe way to do not
loose them in the list archive and to track them.
Thanks for your work and understanding,
Cheers,
--Pierre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG3TXK0hzWbkf0eKgRAvR4AJ9+oVtlS6h78NmmuVBd50TSGtbHMgCdEIPJ
g7pQPJF+oYdwq0OaXXQQ4Xs=
=86lS
-----END PGP SIGNATURE-----
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
