Hannes Magnusson wrote:
[...]
We really need to work on our relationship with other distros,
starting with marking security fixes as security fixes.
Yes, please do mark them as such.
-Hannes
Cheers,
--
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net
--
PHP
Hello Ilia,
we would stick to the rule of only adding to internal APIs in a minor
branch series. Using the pre x.y.0 for time to add, change and delete
functions. I'll write more in a separate thread.
marcus
Monday, December 8, 2008, 10:19:32 PM, you wrote:
How would that model relate to
Hi,
let's take this to a new thread so it'S not hidden in other discussions:
On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans to move to 5.3.0 and still
relies on magic quotes
2008/12/8 Johannes Schlüter [EMAIL PROTECTED]:
Hi,
let's take this to a new thread so it'S not hidden in other discussions:
On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
I do not think it is necessary for 5.3. It is an alpha release after
all and seriously, anyone who plans
On Mon, Dec 8, 2008 at 16:57, Pierre Joye [EMAIL PROTECTED] wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter [EMAIL PROTECTED] wrote:
When dropping magic_quotes the hosting company can do one of two things:
a) not update to 5.3 so we either have to maintain 5.2 for some time or
let
Hi,
On Mon, 2008-12-08 at 16:03 +, Richard Quadling wrote:
But I also understand it is pretty shitty to miss a 1 liner (magic
quotes removed) and find everything broken and then to be told
RTFM/RTFCL.
There's a difference between this and other breaks: Most other BC breaks
change the
Hello Pierre,
Monday, December 8, 2008, 4:57:17 PM, you wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter [EMAIL PROTECTED] wrote:
Hi,
let's take this to a new thread so it'S not hidden in other discussions:
On Mon, 2008-12-08 at 16:06 +0100, Hannes Magnusson wrote:
I do not think
I don't safe stuff relying on magic_quotes is safe but kicking it will
open up way more attack vectors... :-(
In my opinion, this isn't about opening attack vectors (one hole is
all it takes, so they're probably already vulnerable), but removing
mqgpc without fair warning to end users could
On 8 Dec 2008, at 08:18, Hannes Magnusson wrote:
On Mon, Dec 8, 2008 at 16:57, Pierre Joye [EMAIL PROTECTED]
wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter
[EMAIL PROTECTED] wrote:
When dropping magic_quotes the hosting company can do one of two
things:
a) not update to 5.3
Johannes Schlüter escribió:
I don't safe stuff relying on magic_quotes is safe but kicking it will
open up way more attack vectors... :-(
A false sense of security is worst than no security at all.
--
We have art in order not to die of the truth - Friedrich Nietzsche
Cristian Rodríguez R.
On 8 Dec 2008, at 16:35, Philip Olson [EMAIL PROTECTED] wrote:
On 8 Dec 2008, at 08:18, Hannes Magnusson wrote:
On Mon, Dec 8, 2008 at 16:57, Pierre Joye [EMAIL PROTECTED]
wrote:
On Mon, Dec 8, 2008 at 4:47 PM, Johannes Schlüter [EMAIL PROTECTED]
net wrote:
When dropping magic_quotes the
Hi Scott,
Agreed, going from on by default to removed just feels odd.
I'd disable it by default in 5.3 and lets start throwing a strict
error if the configuration enables it.
Why do we have E_DEPRECATED if we're not going to use it?
- Steph
--
PHP Internals - PHP Runtime Development
Steph Fox wrote:
Hi Scott,
Agreed, going from on by default to removed just feels odd.
I'd disable it by default in 5.3 and lets start throwing a strict
error if the configuration enables it.
Why do we have E_DEPRECATED if we're not going to use it?
That's the one I meant, no idea why
hi,
On Mon, Dec 8, 2008 at 5:53 PM, Scott MacVicar [EMAIL PROTECTED] wrote:
I'd disable it by default in 5.3 and lets start throwing a strict error if
the configuration enables it.
A fatal error could be more effective. And the message can make the
reason behind the error very clear.
By the
Pierre Joye wrote:
hi,
On Mon, Dec 8, 2008 at 5:53 PM, Scott MacVicar [EMAIL PROTECTED] wrote:
I'd disable it by default in 5.3 and lets start throwing a strict error if
the configuration enables it.
A fatal error could be more effective. And the message can make the
reason behind the
Hi Pierre,
A fatal error could be more effective. And the message can make the
reason behind the error very clear.
It's a very big jump from 'enabled by default' to 'fatal error'. It will
break a lot of legacy code with no prior warning.
By the way and for the record here, they (magic
In my opinion a big change like droping something that was and still
used by many people are a security measure, albeit a poor one is
something that can only be done in a major release.
On 8-Dec-08, at 10:47 AM, Johannes Schlüter wrote:
Hi,
let's take this to a new thread so it'S not
On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
In my opinion a big change like droping something that was and still used by
many people are a security measure, albeit a poor one is something that can
only be done in a major release.
I concur.
regards,
Derick
--
HEAD before 5_3!:
On Mon, Dec 8, 2008 at 20:15, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
In my opinion a big change like droping something that was and still used by
many people are a security measure, albeit a poor one is something that can
only be done in a major
On Mon, Dec 8, 2008 at 8:38 PM, Hannes Magnusson [EMAIL PROTECTED] wrote:
On Mon, Dec 8, 2008 at 20:15, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
In my opinion a big change like droping something that was and still used by
many people are a security
As much as I hate the feature, I am not certain that is a good idea in
a minor release.
On 8-Dec-08, at 2:38 PM, Hannes Magnusson wrote:
On Mon, Dec 8, 2008 at 20:15, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 8 Dec 2008, Ilia Alshanetsky wrote:
In my opinion a big change like
As much as I hate the feature, I am not certain that is a good idea in
a minor release.
If not now, when?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
6.0 iirc its already off by default in that branch.
On 8-Dec-08, at 3:12 PM, Steph Fox wrote:
As much as I hate the feature, I am not certain that is a good idea
in a minor release.
If not now, when?
- Steph
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
hi,
On Mon, Dec 8, 2008 at 9:48 PM, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
6.0 iirc its already off by default in that branch.
It is not off by default, it has been removed completely. I re
introduced the check function (returning always false) later.
Cheers,
--
Pierre
6.0 iirc its already off by default in that branch.
Ilia, it doesn't *exist* in that branch!
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello Ilia,
given our current development model I completely agree. Thus I would like
to change it as described earlier. I am convinced that only following the
even=stable odd=dev/testing model allows for longer maintenanance cycles
and fast development at the same time.
marcus
Monday,
How would that model relate to patch, minor, major release schemes we
have right now. What you are proposing works for linux, where there is
only one branch and they can effectively do the odd/even approach.
But, what would it mean for PHP and our current versioning schema?
On 8-Dec-08,
Hello,
I don't post here often, but I wanted to input my thoughts. For the
most part, I am a end user who developers PHP applications for mine
and others needs.
We can't just drop something so soon and expect others to catch up and
be able to operate with no problems at all. There is tons
28 matches
Mail list logo