On 30.11.2007, at 00:09, Steph Fox wrote:
Stas - we don't even know what they're planning to put into CVS.
Just
And waiting couple of days for the explanation is of course not an
option.
But opening up a module in the php.net CVS repository that php.net
contributors are excluded from
On 20.12.2007, at 16:31, David Zülke wrote:
No. This Apache CLA most of today's CLAs used by open source
projects (Zend Framework, Cake etc) are derived from require you to
grant an unlimited, unrevocable, royalte-free, blah-blah license to
use your contribution, and, if _you_ hold
On 20.12.2007, at 17:07, Marcus Boerger wrote:
should ever be necessary. And to Lukas, you either violated a signed
agreement here by telling us stuff you learned while being part of
that
group - or you are speculating. You should however not do that!
Maybe not
even IBM is interested in
On 04.12.2007, at 23:41, Steph Fox wrote:
Can I just ask one thing? If namespace support is once again pulled
before it sees the light of a release, can we _please_ document
exactly what the problems were, loud and clear, and put the
document somewhere people are likely to see it?
On 20.12.2007, at 17:57, David Zülke wrote:
Then read it again. It's pretty clear.
3. Grant of Patent License. Subject to the terms and conditions of
this Agreement, You hereby grant to the Foundation and to
recipients of software distributed by the Foundation a perpetual,
On 20.12.2007, at 18:41, Stanislav Malyshev wrote:
grant the same for those patents you own. Those CLAs do not
require that you guarantee that your contribution is not violating
any 3rd-party patents.
Nobody can require that, that'd be stupid - how one can guarantee
nobody has patent to
On 20.12.2007, at 18:58, Stanislav Malyshev wrote:
BTW - I hope you don't think that if you didn't sign the CLA and
you contributed code to PHP that you didn't have rights to
contribute, not signing would help you in any way. Or that if you
contributed code that violates patents, not
On 20.12.2007, at 19:19, Stanislav Malyshev wrote:
Of course. The only difference being that if users of my code
cannot fallback on a CLA as a deflector, they have a much bigger
interest in
Deflector of what? CLA gives the users of the code reasonable - not
100%, but reasonably good -
On 20.12.2007, at 20:54, David Zülke wrote:
Am 20.12.2007 um 19:25 schrieb Lukas Kahwe Smith:
So maybe enlighten me what the purpose of the CLA is.
The purpose is that a project/company/whoever has written
confirmation that the developer who contributes something gives the
respective
On 21.12.2007, at 10:08, David Zülke wrote:
I wonder why they need such elaborate bla bla to just say so
trivial things. The copyright part seems irrelevant given your
assessment and the patent clause seems overly complex if all they
are saying that any patents that are infringed upon by
On 21.12.2007, at 19:38, Stanislav Malyshev wrote:
Sounds to me like we should stop accepting this legal BS. Then
they will only be able to pay for a nice little house if they
write understandable stuff or nothing is they are unwilling to
adapt to the demands of their customers.
It is
On Jan 4, 2008, at 6:37 PM, Robert Cummings wrote:
On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
On Jan 4, 2008 6:20 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
Hello Pierre,
we never accepted this as a pro argument. Infact we often saw the
necessaity to highlight something is optional
Hi,
Ok here is a genious idea. We call for a 24 hour period of silence on
this topic. All people eager to post just re-read all previous emails
and once the 24 hours are over you know what has been said already so
that you can actually make sure to say something novel. What would be
even
Hi,
I am still wondering if we ever going to get a summary of this
discussion.
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Jan 10, 2008, at 1:05 PM, Joe Orton wrote:
I'm not sure I find the logic of the but the system-provided data
will
become stale arguments convincing; systems which are left
unmaintained
by the administrators will have old versions of software on; that's a
given. I can't see why adding
On Jan 10, 2008, at 3:12 PM, Tomi Kaistila wrote:
Well if confusing is the goal, then yes, since this is classic Perl.
I started using PHP, instead of Perl, just so that I would not need
play
around with confusing syntax.
Right, PHP was always about making it easy to see whats going on
On Jan 10, 2008, at 4:51 PM, Ilia Alshanetsky wrote:
On 10-Jan-08, at 10:33 AM, Derick Rethans wrote:
On Thu, 13 Dec 2007, Gregory Beaver wrote:
We don't need moderation, we don't need read-only. We need people
to
follow a simple common-sense checklist.
It's either that nobody saw
On Jan 10, 2008, at 4:55 PM, Antony Dovgal wrote:
On 10.01.2008 18:33, Derick Rethans wrote:
On Thu, 13 Dec 2007, Gregory Beaver wrote:
We don't need moderation, we don't need read-only. We need people
to
follow a simple common-sense checklist.
It's either that nobody saw this mail, or
On Jan 10, 2008, at 8:57 PM, Lukas Kahwe Smith wrote:
On Jan 10, 2008, at 4:55 PM, Antony Dovgal wrote:
On 10.01.2008 18:33, Derick Rethans wrote:
On Thu, 13 Dec 2007, Gregory Beaver wrote:
We don't need moderation, we don't need read-only. We need
people to
follow a simple common
On Jan 11, 2008, at 1:18 PM, Pierre wrote:
+1 (for the record in this thread :)
-1
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I think its painfully obvious that a system to manage the voting is
needed. Like I said, ideally it should also have an email interface.
People should be able to vote from +1 to -1 and be able to add a
comment. Notifications should be send to this list about the start and
final
On Jan 14, 2008, at 4:34 , Pierre wrote:
On Jan 14, 2008 2:58 AM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Voting to achieve what?
Fair decisions in a simpler, effective and right manner (and not
discutable, ideally).
I do not consider fairness, whatever that could mean, having
On Jan 16, 2008, at 9:17 , Stefan Esser wrote:
Stanislav Malyshev schrieb:
@Richard: You don't understand the Problem with _REQUEST. It is not
about the fact that someone can forge GET, POST; COOKIE variables.
It is about the fact that COOKIEs will overwrite GET and POST data
in
REQUEST.
On Jan 16, 2008, at 11:55 , Stanislav Malyshev wrote:
I dont understand the problem. You use request if you do not care
where a parameter is set and you use the other superglobals when
you do care.
The problem is that variables_order should specify what gets into
_REQUEST (as documented
On Jan 17, 2008, at 10:17 , Stefan Esser wrote:
When someone injects you a cookie like +++action=logout through an
XSS or through a feature like foobar.co.kr can set cookies for
*.co.kr
(in FF atleast).
Ok, you are assuming one security issue here, that is not related to
the topic.
On 22.01.2008, at 04:14, Andi Gutmans wrote:
I don't think this affects PHP 5.3 (http://wiki.pooteeweet.org/PhP53VoteResult
) which I believe we're making good progress on. It allows us to get
some of those features out earlier including things like namespaces
which the various framework
On 01.02.2008, at 23:05, Pierre Joye wrote:
2008/2/1 Marcus Boerger [EMAIL PROTECTED]:
Crosspost, hopefully silencing this issue for 5.*
AND 6 will have an E_WARNING or even an E_ERROR on this.
What are the gains?
What are the real reasons behing strictness? I really get annoying by
Hi,
I know I have been guilty of formulating my concerns about PDO's
history in an unfortunate way that turned out to sound more like a
personal attack on Wez, than a sound technical commentary (which is
all that counts on an OSS mailinglist). So I cannot pretend to have a
white vest in
On 03.02.2008, at 10:16, Lester Caine wrote:
Steph Fox wrote:
Hi Marcus,
what I want is php-src as minimum you can depend on. And php-
default as
release managers playground. The RM can then say what he thinks is
mature
enough to make it into a release.
What _I_ want is a PHP core that is
On 03.02.2008, at 18:24, Steph Fox wrote:
Hi Marcus,
Anyway my idea is to start everything in PECL and
to to move everything out that can be moved out. And that includes
all MySQL
extensions as well as SQLite. Only this way people will use the PELC
infrastructure. Otherwise we would just
On 03.02.2008, at 19:24, Steph Fox wrote:
I see no point to discuss solutions for some unknown entities willing
to contribute when they do not consider to introduce themselves.
When
they don't explain clearly why we should do the move and what will be
the actual gains for us (read: for us
On 03.02.2008, at 20:04, Steph Fox wrote:
Moin Lukas,
Now, PECL has a couple of CLA'd modules already. I don't like
them being there, and you have stated your own opinion loud and
clear. I think we should be looking for some way to separate out
CLA'd PECL modules to elsewhere but
On 04.02.2008, at 11:38, Marcus Boerger wrote:
Hello Ben,
None of this is necessary though. What I proposed was moving
extension
development from php-src to PECL an dthen bundle what we see fit
into the
distribution just as we do now, whith the RM having the last say
what goes
in and
Hi All,
Just a suggestion. Maybe make your case analyzing a set of
representative php applications for calls to the various is*() methods
(maybe even factoring in assert()). This could help in showing how
often people are currently forced to write out type checks.
My humble guess:
On 07.02.2008, at 00:59, Pierre Joye wrote:
Hi Andi,
On Feb 7, 2008 12:56 AM, Andi Gutmans [EMAIL PROTECTED] wrote:
-1
Suggestion to enhance the suggestion: return false + emit E_STRICT
message (but I am also fine with pure return false if people don't
like
this suggestion).
Sounds
On 08.02.2008, at 17:46, Pierre Joye wrote:
On Feb 8, 2008 5:38 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
Frankly, I don't see why there is any vote whatsoever. It's plain
stupid to consider removing them when a fully backwards-compatible
solution exists that has no performance penalty,
On 13.02.2008, at 21:52, Andi Gutmans wrote:
Guys,
I think we are over-engineering and over-complicating here. Reminds
me of all the ugly workarounds in C++.
If this is really what you need then just declare it private/
protected and create accessor methods (getters/setters).
I don't
On 14.02.2008, at 04:04, Steph Fox wrote:
Tell us the names of these entities, companies or persons, who are
going to contribute and what are actually their requirements. What
will they bring (saying expertise is not something I can buy)? I
don't understand what is so hard to understand that
On 14.02.2008, at 10:20, Markus Fischer wrote:
Lars Strojny wrote:
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for
seperate
funcs?:
On 14.02.2008, at 10:07, Lars Strojny wrote:
Hi Jochem,
Am Donnerstag, den 14.02.2008, 00:56 +0100 schrieb Jochem Maas:
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate
funcs?:
set_include_path('foo',
On 14.02.2008, at 22:07, Christopher Jones wrote:
Pierre Joye wrote:
You (as group)
We are individuals, all members of the mail lists.
Ok, could the Microsoft and IBM people on this list please speak up
then? Could also one of the Oracle internals guys speak up on this
list? That is
On 14.02.2008, at 22:19, Christopher Jones wrote:
Lukas Kahwe Smith wrote:
On 14.02.2008, at 22:07, Christopher Jones wrote:
Pierre Joye wrote:
You (as group)
We are individuals, all members of the mail lists.
Ok, could the Microsoft and IBM people on this list please speak up
On 14.02.2008, at 23:06, Christopher Jones wrote:
I think most multi-person plans that impact an existing OSS project
have had some genesis in private discussions before being broadcast.
For PDO V2, this discussion was just really slow and intermittent.
Yeah, I am basically fine with this. I
On 16.02.2008, at 02:14, Lars Strojny wrote:
I've heard that E_DEPRECATED is still missing nevertheless its
introduction is planned for 5.3. So I've wrote it [1] based on a
slightly outdated patch by Felipe. The patch is so far complete, as
far
Thx!
as I can tell, but one thing I'm
On 16.02.2008, at 11:05, Marcus Boerger wrote:
Hello Steph,
so here's my take on the matters. For 5.4 we collect ideas and
implement
them. So that 5.4 comes out with mostly PECL. I guess we can collect
action
items on Lukas' wiki.
Well maybe we should target this stuff for PHP6 for
On 18.02.2008, at 15:04, Paul van Brouwershaven wrote:
Hi Lars Markus,
Lars Strojny wrote:
As safemode is going to be (finally!) removed in PHP 6, I would
propose
not to make this dependent on safe-mode. I would rather allow this
feature to be enabled separetely in the php.ini. Something
On 19.02.2008, at 15:32, Marcus Boerger wrote:
In fact I'd love to issue a deprecated message as soon as class is
found
outside of a main block.
err .. deprecated?
as in you want to deprecate the possibility entirely?
or you just want to hin to the user that its a bad idea .. (not sure
On 19.02.2008, at 00:22, clynx wrote:
I have thought about a new feature for some days now. The initial
plan was to create a new keyword deprecated which should simply
trigger a warning when the right error level was set. This could
have been combined with the E_DEPRECATED level from 5.3
Hi,
I really like what Stefan did here with his traits RFC. Very solid
work, even if there are still some people not convinced if they want
this feature in, I have seen little complaints about the way this
proposal was made. Quite the contrary actually. I would like this kind
of detailed
On 20.02.2008, at 09:28, Stefan Marr wrote:
Hi Lars,
What about abstract methods in traits? I think this could be handy to
enforce the user class implement a data getter.
trait Foo {
public function doSomething()
{
return str_replace(foo, bar, $this-_getString());
}
abstract
On 20.02.2008, at 21:43, Stefan Marr wrote:
If we feel it gets necessary we probbaly
might want to support a syntax like:
'trait_method' = false
'trait_method' = 'new_name'
'trait_method' = array('new_name', 'trait_method'
I'm not comfortable with this notation, since it strengthens the
On 21.02.2008, at 03:26, Andi Gutmans wrote:
a)
I think Traits should be able to act as a self-contained behavior
which can always be expected to work. For example if I want a
Counter behavior I would like that not to depend on the properties
in the containing class. While I don't think
On 21.02.2008, at 07:55, Gregory Beaver wrote:
Simply re-using trait instead of use is a more self-documenting
solution. I found it slightly confusing to see use when that is a
namespace-specific token currently. This is also in keeping with the
way functions are defined in interfaces vs.
On 21.02.2008, at 19:09, Andi Gutmans wrote:
I don't think so. I think the value here is not copypaste but to be
able to encapsulate some functionality which a class can be
decorated with. Giving a basic storage mechanism to that would be
very beneficial in a large amount of uses. Again,
On 22.02.2008, at 06:56, Gregory Beaver wrote:
Another detail: The implementation of the parser changes should still
allow a class or function called trait, i.e. trait should only
be a
keyword at specific positions in the source to avoid unneccesary BC
breaks. The current patch has this BC
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should
Hello all,
Let me briefly pick on poor David's (unfortunately I could have picked
any number of posts on any given day just as well) recent emails [1]
[2]: they are prima example of very bad quoting. Again I do not expect
everybody to read through the mailinglist README [3] from cover to
On 22.02.2008, at 23:31, Gregory Beaver wrote:
I think you may be confused, because your statement about
refactoring is
inaccurate - for most methods, there would be no change from the
current
proposal. In other words, in my example above, you could use
trait1::a() simply as Blah::a, for
On 22.02.2008, at 18:20, Stanislav Malyshev wrote:
Hi!
A trait may contain methods and properties. When importing a trait
into a class, all methods and properties are imported in a way that
makes them only visible within the trait (I dont like the use of
private
How you are going to
Hi,
Ok, since there seems to be controversy about how to best collaborate
on documents like TODO lists, RFC's, README's etc. and I do not want
to piss people of by making final decisions on this in a closed
circle. Here it goes. Honestly I do not think its a big issue either
way as long
On 25.02.2008, at 17:20, Stefan Marr wrote:
Pierre Joye schrieb:
Limiting the RFC to existing php.net's member sound like a bad idea
and create CVS accounts only for a RFC does not sound any better.
I would rather use the wiki for the complete process. Once a RFC
reached a stable status, we
On 26.02.2008, at 04:19, Gregory Beaver wrote:
My only objection is that this introduces two new keywords, trait and
instead. In addition, this can get very awkward if multiple traits
(more than 2) implement the same method name. I would prefer a simple
recycling of the = sign for both use
On 28.02.2008, at 15:19, Marcus Boerger wrote:
Hello David,
Wednesday, February 27, 2008, 9:27:16 PM, you wrote:
Greetings, PDO community! My name is David Sceppa and I am a program
manager working at Microsoft on improving SQL Server for PHP data
hosting.
Thanks fro writing and
Hello,
First up, I have been quite outspoken against CLA'ed code in PECL in
the past. With the current proposal I am willing to reconsider this
position. The main difference to me is that is that I expect the
different vendors to take a much more active role in the development.
This
On 03.03.2008, at 00:48, Alan Knowles wrote:
Can you clarify the Multibyte issues:
- I presume this means that it can handle ASCII/UTF8/16 etc. but
will not handle things like BIG5/GB encoding in source code - this
may be a bit of an issue around here..
At first I also thought that
Hi,
Ok so we have a wiki up and running at wiki.php.net. It is integrated
with master.php.net, so you can use your cvs password to login. Pierre
and I are currently the only ones with admin accounts, but aside from
administration of ACL's etc anyone with a CVS based login can create,
On 05.03.2008, at 18:54, Pierre Joye wrote:
Hi Stan,
On Wed, Mar 5, 2008 at 6:41 PM, Stanislav Malyshev [EMAIL PROTECTED]
wrote:
Hi!
Ok so we have a wiki up and running at wiki.php.net. It is
integrated
Great! Thanks a lot!
I should have also mentioned that in fact Pierre was the
On 06.03.2008, at 00:45, Lars Strojny wrote:
Hi,
Am Mittwoch, den 05.03.2008, 18:54 +0100 schrieb Pierre Joye:
[...]
Yes, that's the plan. Lukas will do it as far as I remember. I also
updated the syntax hightlighter (code tag), it sill uses Geshi but in
a nicer way (for those interested, it
On 06.03.2008, at 09:26, Pierre Joye wrote:
On Thu, Mar 6, 2008 at 2:23 AM, Lars Strojny [EMAIL PROTECTED] wrote:
Hi,
Am Donnerstag, den 06.03.2008, 01:24 +0100 schrieb Pierre Joye:
[...]
Maybe SOC:2008, using SOC as namespace and 200X for the main pages
is better.
I like that. Is it
On 06.03.2008, at 21:40, Pierre Joye wrote:
Hi All,
1) php internals (php-src, qa, docs etc)
2) any other php.net subproject
3) other php projects
if a proposal falls in 3) it needs to be really good and all the
prosals left in 1) and 2) need to be pretty unexciting in order to be
Hello Banko,
I remember that you proposed an ORM written in C/C++ last year around
the same time. Back then I was quite opposed to the idea, saying that
something like this best belongs in userland, and that at most certain
bottleneck features should be moved to C (following the example of
On 26.03.2008, at 20:55, Stanislav Malyshev wrote:
Hi!
I don't think I've ever said I don't like short tags. It's not the
issue here. The issue is that allowing to change it during runtime
adds more WTF to PHP. WTF factors are bad.
2. For any code messing with this value - and this
On 26.03.2008, at 22:05, Stanislav Malyshev wrote:
never heard of XPath.class.php and also never heard of some
code deep inside this Xayara CMS.
And used by people. Did I or anybody here on the list actually
contacted with these people or not does not matter - we can't
contact millions
On 26.03.2008, at 17:56, Pierre Joye wrote:
On Wed, Mar 26, 2008 at 5:39 PM, Stanislav Malyshev [EMAIL PROTECTED]
wrote:
Hi!
- Added runtime JIT auto-globals fetching and caching. (Dmitry,
Sara)
Does this change any semantics, etc? Any reason why it wasn't
merged in
the first place?
On 26.03.2008, at 14:04, Felipe Pena wrote:
So what is the conclusion here?
- Added runtime JIT auto-globals fetching and caching. (Dmitry, Sara)
backport (based on the arguments from Pierre)
- Added jump label operator (limited goto). (Dmitry, Sara)
backport
- Removed support for
Hi,
I unilaterally put in a regulation in place on the wiki on how to
deal with competing/extending proposals, where the original RFC
creator and would be contributors cannot agree on how to integrate the
differences into the original RFC [1]. I already made a note of this
on the wiki
On 03.04.2008, at 10:42, Raphaël Rougeron wrote:
I need access to the php-testfest-web module in order to contribute
to it
I trust that Raphael will do a good job here. For those of you that
have attended PHP Quebec this year, he was one of the speakers from
Paris.
regards,
Lukas
--
On 07.04.2008, at 18:49, Christian Schneider wrote:
Felipe Pena wrote:
Right, this shouldn't even be on the agenda before we have scalar
type
hints. So, perhaps you can make a patch for that first Felipe?
I don't thought this before!
Sure, i'll try provide a patch.
Just so this side was
On 07.04.2008, at 18:57, Stanislav Malyshev wrote:
Hi!
I just ran into this (IMHO unnecessary) limitation with array_reduce:
Why should it only reduce to an int? Why not a string or an array? I
plan on submitting a patch for PHP 6 to allow other types too.
I'm not sure I understand - how
On 03.04.2008, at 15:47, Ligaya Turmelle wrote:
I wish to help with the testfest. Lukas told me to start asking
some questions in here. So to help organize things I will add this
information to the testfest wiki page and if you want pass on any
changes for the testfest web page (or you
On 11.04.2008, at 21:30, Ryan Panning wrote:
I have been wondering the answer to this question for a while now. A
LOT of stuff has been backported from PHP 6 to PHP 5.3. So much in
fact, why don't you just call PHP 5.3 version 6?
What major new features are left for PHP 6? The big one I
On 11.04.2008, at 21:41, Ryan Panning wrote:
Lukas Kahwe Smith wrote:
Native unicode is not big enough for you?
regards,
Lukas
If you're looking for good PR and reviews, no. I think if you have
very limited new features, the people writing reviews are going to
say PHP 6 doesn't have much
On 08.04.2008, at 12:13, Krister Karlström wrote:
Yes indeed you can implement it using the __call method, but it
would be more readable if the language structure itself would
support it. I suggested this just because I think that this is the
most common way of using overloading, thus this
On 07.04.2008, at 19:59, Stanislav Malyshev wrote:
Hi!
Right if at all I would agree on having a type hint scalar, but
not a separate one per type.
IMO (as already was discussed like 10 times?) scalar makes no
sense. It doesn't save you any checks, and doesn't provide any
useful
On 14.04.2008, at 19:49, Christian Schneider wrote:
Am 14.04.2008 um 19:04 schrieb Chris Stockton:
You are missing the point, why be strict on return types, and
liberal on parameters? Be strict
Because IMHO a function can easily specify what it is returning but
should be flexible in what
Hello All,
I just want to bring in a different perception on the proposed
feature. I think people are very focused on what I call library
code. This is the kind of code that should in theory be worked on
less, than the glue code that you write in every project to finish up
the
On 05.05.2008, at 20:51, Pierre Joye wrote:
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
It's just simple to make constructors work in the same way in
namespaces and
out of them. It would be difficult to explain why the first script
prints
ok and the second
On 07.05.2008, at 18:35, Andrei Zmievski wrote:
As far as I remember, the latest point was to remove the
unicode_semantics switch and presume that its value is always On. At
the same time we said that binary strings should probably be the
default string type (which I don't agree with),
On 19.05.2008, at 23:34, Cristian Rodríguez wrote:
Andrei Zmievski escribió:
Done. See latest commit: switch is removed and mode is defaulted to
On.
Thank you , VERY MUCH Andrei, now we can **really** move forward..
well the next question is binary or unicode as the default for
strings
On 19.05.2008, at 15:40, Marco wrote:
This could be a silly question but one of the things that I struggle
with
whilst developing my applications is the lack of WSDL generation in
the PHP
Soap extension and the need to secure my SOAP messages using signing
etc
which isn't really
-1
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
. It should
hopefully be a fairly low effort way for extension authors to get
their test coverage up a bit and maybe they will get regular test
contributions for their extension of all goes well.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
[1] http://testfest.php.net
--
PHP Internals - PHP
On 12.06.2008, at 20:52, Lukas Kahwe Smith wrote:
So we still have a number of unreviewed submissions in the TestFest
bug tracker [1]. We need people willing to review these submissions.
The process is quite easy, just head on over to the website, pick a
submission, assign the submission
On 12.06.2008, at 16:31, Pierre Joye wrote:
- interbase
- fbsql
- sybase and sybase_ct
I think moving fbsql is quite reasonable. However interbase and sybase
I do not agree with.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
the docs. See no
evil, hear no evil, speak no evil.. ;)
I do not know the decision (anyone who cares about decisions being
remembered should write an RFC nowadays), but I think what Jani is
saying sounds reasonable to me.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals
On 14.06.2008, at 16:24, Pierre Joye wrote:
On Sat, Jun 14, 2008 at 3:24 PM, Lukas Kahwe Smith
[EMAIL PROTECTED] wrote:
On 12.06.2008, at 16:31, Pierre Joye wrote:
- interbase
- fbsql
- sybase and sybase_ct
I think moving fbsql is quite reasonable. However interbase and
sybase I do
in
5.3.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
the shouting.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
understanding we still do not have any example of this being used in
the wild ..
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
entire words, please
take a deep breather and hit deleted instead.
regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]
PS: How about instead sending a mail to the firebird foundation, to
which you seem well conntected, and see if they can help?
--
PHP Internals - PHP Runtime Development Mailing List
1 - 100 of 846 matches
Mail list logo
