On 29 Oct 2002, Timm Friebe wrote:
>* Do I commit this against head or against php_4_3_0pre2?
> (cvs com && cvs tag -F php_4_3_0pre2 or simply cvs com)?
HEAD.
>* buildconf says: "You need bison version <= 1.30 >= 1.75 installed
> to build PHP from CVS" - I'm running FreeBSD 4.7-STABLE, bison
> from ports is 1.35_1 *and* "You need libtool version 1.4 or newer
Those are the requirements. Not our problem to solve those for
you, do as you feel best. Compiling from sources sounds like
a good idea. (for bison, use 1.28 version)
>README.CVS-RULES > 6. Test your changes before committing them.
> We mean it. Really.
>
>As promised, I compiled it into php-4.2.2 under FreeBSD and under Debian
That means that you test that your changes to CVS HEAD
work before you commit them to CVS _HEAD_ not some old release.
>README.CVS-RULES > [...About CVS log...]
>This is what I would write:
I should rewrite that thing..
># Add myself to authors
# is not needed here.
>@- Take care of feature/changes requests by myself in (Bug #16960):
>@ * Implement unbuffered queries
>@ * Fix up sybase_fetch_object not to return objects with numeric
>@ members
>@ * Fix issues with identical fieldnames
>@ * Set data types returned to their equivalents in PHP if possible
>@ * Add server message handler
>@ * Add a new ini setting for deadlock retries, defaulting to
>@ "forever". Deadlocks within transaction can cause @@transtate
>@ to output uncorrect values if they are retried.
>@ * Add a new function sybase_fetch_assoc
Please READ the NEWS file in HEAD and compare it to this.
Does any entry in it look like this?
Added, Fixed, Removed, Made. (past tense!)
(Take care? Huh?)
>@- Make sybase_query errors more verbose
>@- Make phpinfo() output more verbose
>@- Add mssql-aliases to all the new functionality
>
>Is this too short? Or to long?
Both. Read the NEWS file entries for 4.3.0 carefully.
Every entry needs to have your name behind it:
- Made sybase_query() error messages more verbose. (Timm)
Notice the ()'s? And be verbose but not too verbose in
these NEWS entries too.
>There are four open bugs for ext/sybase_db. I don't use this extension
>and its usage is discouraged anyway (see
>http://www.isug.com/Sybase_FAQ/ASE/section7.html#7.2).
Move it to PECL then.
>There is one open bug for ext/sybase_ct concerning compute results and
>multiple results, pointing to:
>
>* http://bugs.php.net/bug.php?id=11475
> This breaks functionality on further queries, producing weird
> results. If you can't handle multiple resultsets, you *must* cancel
> them!
>
>* http://bugs.php.net/bug.php?id=13735
> Bogus
>
>* http://bugs.php.net/bug.php?id=12074
> Feature request for unbuffered_query:)
>
>* http://bugs.php.net/bug.php?id=13475
> http://www.marden.org/php-sybase-ct/ gives me a 404
> I'll have a look at it nevertheless
Bogus -> Mark it as such and be done with it.
Feature request -> change the category to "Feature/Change Request"
Try always first to get them to test the latest snapshot.
(Use the quick-resolve select box, or the urls in the mails on php-bugs list)
>As I can only test my development on FreeBSD (4.3, 4.7) and FreeTDS
>(0.60) w/ Sybase (11.0.3.3/Unix, 12.5/Linux, 12.5.0.1/Sun) and Debian w/
>native Sybase-libraries Sybase (12.5/Linux, 12.5.0.1/Sun), I'd be happy
>about any feedback on other systems and constellations.
We use users for testing. See above comment about snapshots..
--Jani
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
