Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63897 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51161 invoked from network); 16 Nov 2012 00:40:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Nov 2012 00:40:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=ircmaxell@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ircmaxell@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender) X-PHP-List-Original-Sender: ircmaxell@gmail.com X-Host-Fingerprint: 209.85.215.42 mail-la0-f42.google.com Received: from [209.85.215.42] ([209.85.215.42:60851] helo=mail-la0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D0/C1-41238-D6B85A05 for ; Thu, 15 Nov 2012 19:40:14 -0500 Received: by mail-la0-f42.google.com with SMTP id s15so1789783lag.29 for ; Thu, 15 Nov 2012 16:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=spFYA95e42U/4MvY3rsH7dxJmL9dxDY/KpmoUJMPQUo=; b=QtkUPs5SRa+Lj9vwj9LpkuruoMPj9Mzfup/4igXFp9ne5ppC5y5rD6yb4kUy43BNVB cfmkLa/uFY3g+Robnpxz+fnZLtCn+cWaIGdRvevVtSD6ujpPJF0/hwVvSfFk4pvGbVKb vPrdSHj47GkwsPCYyMUQd2rhGLkSvtm7OwcNaORNs5xd2EYxqEZU2eD4xAwTvgA7y+N3 yLN/o3GPrXCR/zyiirCjrJIuuRjEoM42vYRotx1rkYKRjHkeS1/zHlWvgLwh5+esiQLd rwUR0KDl5WsJQ0RggmYVztndSQJRMX3p3VqsPup7HveAn0dX5AkcT9+N8wqYQz88fMJu Dm0w== MIME-Version: 1.0 Received: by 10.112.45.165 with SMTP id o5mr1277096lbm.74.1353026410982; Thu, 15 Nov 2012 16:40:10 -0800 (PST) Received: by 10.114.14.168 with HTTP; Thu, 15 Nov 2012 16:40:10 -0800 (PST) In-Reply-To: References: <50A10A9D.9070402@oracle.com> <50A1946F.8010407@lerdorf.com> <50A20CCB.8090909@lsces.co.uk> <8A8A29F9E43E417FB5450D63019B2DDB@NeiRoze> <8f4231fc-6e3c-4a33-af71-2af5e7a95dfd@email.android.com> <50A2D672.7010600@gmail.com> <50A30144.5070305@phpgangsta.de> <50A3BEC0.8030607@gmail.com> <50A54713.8090102@sugarcrm.com> <50A549EB.2020408@lerdorf.com> Date: Thu, 15 Nov 2012 19:40:10 -0500 Message-ID: To: Sherif Ramadan Cc: Will Fitch , Rasmus Lerdorf , Stas Malyshev , Adam Harvey , Devis Lucato , PHP Developers Mailing List Content-Type: multipart/alternative; boundary=bcaec554de2e992de804ce92023c Subject: Re: [PHP-DEV] RFC: ext/mysql deprecation From: ircmaxell@gmail.com (Anthony Ferrara) --bcaec554de2e992de804ce92023c Content-Type: text/plain; charset=ISO-8859-1 Sherif, I'm just trying to understand your reasoning behind this view. > > How is "telling people it's deprecated, but only in the manual" going > to be any different than "putting warnings to discourage future use, > but only in the manual"? > I'm not saying to put it only in the manual. I'm saying we need to make it clear in the manual. And then we need to go on an education campaign by speaking in conferences, blogging, writing tutorials, reaching out to the sites that host bad ones and trying to get them to switch. Basically make an actual effort to convey the gravity of the situation, rather than just writing a quick quarter of a paragraph note "We recommend you don't use these"... > 1) People who use mysql_* will rarely ever look at the manual to see them. > I don't have stats, but in the people I've talked to who use that functionality (in chat rooms, etc), they often link directly to the docs. That may be overestimating the population, but I think more people read the docs than you think. Now, they may start to use it before they look at the docs (from tutorials), but they will likely visit the docs at some point... > 2) Even if they do they do what makes you think this is more effective > than seeing the warning in their logs? > It's not that it's more effective. That's not what I'm after. If I was after "effective", I'd say let's remove it in 5.5. That's effective. But it's also not *good*. I want to give reasonable people a reasonable chance. And by controlling the message, I think we can do that. > 3) Even if it was more effective, what makes you think it will result > in any kind of action beyond that of which the warnings would result? > There are going to be some people who will never change. And there's nothing we can do for them. But we can try. We have to try. If we don't, we're not doing our users justice... > Sorry, I don't see any kind of indication that putting things in the > manual is going to show "the gravity of the situation" any more than > the deprecated errors will. Again, I'm not limiting it to the manual. The manual is the "reference" point for proving that it's deprecated, but it needs to be a community effort, similar to how GOPHP5 was... > We're not discussing introducing new features here. We're discussing > the deprecation of old features. Right, but you're quoting how projects like Wordpress don't use 5.4. And I pointed out that it runs fine on 5.4, it just doesn't take advantage of specific features. That people haven't upgraded their servers is another point entirely... > How are we ignoring anything in future planning by giving people what > could potentially be several years before the extension is removed. In > the mean time, we have E_DEPRECATED errors being thrown (again in PHP > 5.5, which likely 95% of those CMS frameworks you mention that depend > on ext/mysql won't ever upgrade to), and the necessary migration guide > and warnings in the manual. > Those platforms will likely support 5.5. They have in the past. And they will going forward. Saying 95% won't upgrade to is a non-argument. The users may not, but the platforms will (especially the hosted ones, as recent performance improvements and security updates alone will mandate it)... And you also hit on another big point. You are mentioning the adoption rate of new versions. That it's abysmal. And that's very true. It's also a huge problem that I think we need to solve. And we can solve. By limiting BC breaks. By communicating effectively. By listening to the community, and interacting with them. By being proactive rather than isolated from them. I don't want to ever hear the excuse that we can do something because it'll be 5 years before "they" will be effected. That's the wrong attitude. It just perpetuates the problem of slow adoption. We should instead be lowering those barriers. And one of the best barrier-lowering tools is clear and healthy communication. We're leading people into a sane migration path that will never happen > if all we do is confuse them by saying one thing in the manual and > doing nothing in the code. Most people will probably just take that as > a sign of "nothing has changed... just keep doing whatever you're > doing" > I think going from "not recommended" to throwing notices all over the place is worse. It's like blindsiding them. We should at least try to get the message out in a controlled manner, with a hard plan that people can understand. If they chose to ignore it, that's their problem. But we should be the bigger project... > I'd rather see those warnings and have the information in the manual > and urge those projects to start finding a suitable migration path for > the next year or two than spend a year convincing myself that people > will do anything about ext/mysql code just because we're telling them > its deprecated in the manual. > I would as well. Next release. When they have had time to heed the warning. > I think you greatly under-estimate who reads the manual and who has > the power to modify/affect these OSS frameworks/CMSs to move away from > ext/mysql. > If I under-estimate anything, it's the history that core has had in relating to the projects. For a long time it's been a very "us-vs-them" attitude (or looked like it from the outside). Lately, better cooperation and collaboration has been happening. I believe that the community can be strengthened. And the first step of that is to trust and try to build that interaction again. If those projects don't change, I don't want it to be because of lack of what we did. I would rather it be that they ignored us. And I would rather it be that we work together to protect them, rather than seeing them as outside of the community, or as people who don't matter. > Only when they have tens of thousands of users breathing down their > upstream's neck about getting warnings will there be some justifiable > stake for those upstreams to start taking serious action. I believe > the most popular ones like WP have already demonstrated they are > heading in that direction now. > If they are, then so be it. But that doesn't mean that we shouldn't try... Anthony --bcaec554de2e992de804ce92023c--