Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:125770 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 69CFD1A00BD for ; Wed, 9 Oct 2024 01:48:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1728438674; bh=+l0AVefcoJaJH1/1rS95MhbGCJ1xlkZjbMnHCRbdXho=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=dc+k/m81pJ8Dm+gsv9/DSuGVYl69+EhueCINRwyxHJ3aa6JGf9PQPWxQEp8nIJu11 j784GB7Vfhd3HlVx37uEfA699seovrgacG+iHBNOdrwK0xAv8xkN8URV2rwEb8EYCe ib7ifWAGkuyhFVcTkaQgLzXl26jZ8NYju1tGWCAHWLONylGfSZi2fU3oPOqkwdfYLc VrnL8WjtiJLVgfzdLu0hN00vSffV10K/tVFO3f/mjJ6HPpHdgJCC+JZfttCLSWBYIY V2N8kkkIrrAYB05I8ltSdjvQVP2GJavVuruTa9kz4dIfUgyDDiyNXrVPEVN+qCousF HLp3PG7hplnMg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1C3C918004D for ; Wed, 9 Oct 2024 01:51:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DMARC_MISSING,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 9 Oct 2024 01:51:12 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-e28fc40fdccso510616276.1 for ; Tue, 08 Oct 2024 18:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=newclarity-net.20230601.gappssmtp.com; s=20230601; t=1728438534; x=1729043334; darn=lists.php.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=gymqudKqIr/ypH8bWRCMVm/F/tXSUXoWHthQFOOzvHk=; b=ur5eZZJS0IV6vr7Op8kS8xH8Hj/RBWvsiZXQc/Vkt/rToWkpW+EWHZmFvvIxAO549Q w8AZyng6uegYzca0bC8olIcTQFNXOwg0pm0evYZIDCXs6mY9J1ivzZUAWdpTumjClWga S3FcVoHwzeXN6/qfQMVKRttxVueL4itKUQpwAAAz++iNelrabYgVFwBRK5qBlqTuz/JP 3+HuvOt+JuHcIf4V5CXa6hqt+w0BiPEwXPHJnNvjsclOLjnIEowGzcuzS5L0IYkLggt+ cgHtfuOhHb5bsth4U/WKhah1tl0orTT66sw6ptjw+FwxFWKT+tSO7odf4RBgDtpnXwsw XMgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728438534; x=1729043334; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gymqudKqIr/ypH8bWRCMVm/F/tXSUXoWHthQFOOzvHk=; b=KUsXkaV+WdCe+VgeyfJquTEDhzhOPZ5NlzINtLyhyg95KiXtsk1We251LOIeEmC38U 79QTbwW9bkqWCNMIkkSbHIzcJ0KL/+ApvhaaEpEpYjAnf8cJ6x1AwHVXAnFSYSwIgVQz N9gZ/0AlC1YuCI55+ZqtOMYHaQ0vb+lkE51QlwSdpZQpcrDVAjY7IjWtWIRNxn8L55Ub xA1sCIpgXr/t7k71ZpJMaqHh9UejRwYxLFKqbXuWu+k5Wzfw+Z/k7Npy8hqe3kUhgGKR ubGogXBN8kT3e49ljQ7VUInt6tDVb5yl8wa6j5APjSDCdOpFOGWVphXe19UwXFVtwoZl nL/Q== X-Gm-Message-State: AOJu0YxqiMTSoyigtR3PZM9/+8mCp9NipCvWOKQYtpxbCssAntsmm770 jERAicTMLeeSVgrU5hYu9TrldKy1VyxVKmC4vsQ3nzUp1MiCAf/DY1fDZO9VelTaLMlrmOPmrnG AROE= X-Google-Smtp-Source: AGHT+IEcOyBPkRfSzkTxVl+L8u1lOUUyQHiGmE+sE32YbUA9oMYXoY+KGG6fZPbKMbWwyHUPRYDlCw== X-Received: by 2002:a05:6902:161d:b0:e26:f12:1dd9 with SMTP id 3f1490d57ef6-e28fe36132bmr1050270276.13.1728438533815; Tue, 08 Oct 2024 18:48:53 -0700 (PDT) Received: from smtpclient.apple (c-98-252-216-111.hsd1.ga.comcast.net. [98.252.216.111]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e28a5cc6432sm1484050276.59.2024.10.08.18.48.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Oct 2024 18:48:52 -0700 (PDT) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_1EB71F07-6A02-47DB-B790-B542526B5CF7" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: [PHP-DEV] [RFC] Policy on 3rd party code Date: Tue, 8 Oct 2024 21:48:51 -0400 In-Reply-To: <60dd81ad-7232-48a4-b419-48066bf15197@app.fastmail.com> Cc: internals@lists.php.net To: Jim Winstead References: <92b537ac-62f4-435c-bf55-07223cfa1915@app.fastmail.com> <1E3250E0-17C7-4BCD-9A5F-7F2FED48686D@newclarity.net> <60dd81ad-7232-48a4-b419-48066bf15197@app.fastmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.10) From: mike@newclarity.net (Mike Schinkel) --Apple-Mail=_1EB71F07-6A02-47DB-B790-B542526B5CF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 7, 2024, at 7:31 PM, Jim Winstead = wrote: >=20 > What is currently blocking content that at least one unpaid volunteer* = wants to contribute in a way that leverages the existing technical = infrastructure is that there is vague, unwritten policy that we don't = mention third-party tools in the PHP documentation, except for all of = the third-party tools that we already mention in the PHP documentation. I am totally with you on this, and I apologize on my part if anything = about what I said made people view it as an either-or proposition.=20 Instead, I intended comments were intended to be viewed as "Yes, and..." > On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel wrote: >>=20 >> IOW, given that all the current infrastructure really supports are=20 >> static pages =E2=80=94 without a gargantuan effort to write and = maintain a=20 >> custom framework from scratch by unpaid volunteers =E2=80=94 the = resultant=20 >> website can only realistically be static pages.=20 >=20 > Developing and maintaining the PHP websites is far from a gargantuan = effort, as evidenced by how it is currently (and has long been) = maintained on a very ad-hoc basis by a very small number of volunteers = with some work that is now sponsored by the PHP Foundation. (I believe = that amounts to maybe the equivalent of one full-time person.) What I was thinking when I spoke of a "gargantuan effort" was if a team = were to try to duplicate the functionality of a modern website vs. just = maintaining the aging and minimal website that is currently php.net = . =20 > I think a proposal for the PHP project taking on something like = centralized databases of "all" third-party packages also needs to come = up with a very good rationale as to why that will turn out differently = than how PEAR and PECL did. That rationale is an easy one.=20 1. First, both PEAR and PECL are package managers. I was proposing a = directory. Directories are an order of magnitude easier to manage than = a package manager. 2. PECL was an extremely high bar as it was a package needed to be = written in C, so we should just ignore that one. 3. PEAR had huge friction because (from what I understand) it required = approval from members of the PEAR Group to be included. Let's instead compare to examples that turned out very different from = PEAR and PECL, and although are arguable also package managers it is = their directory aspect that I am focusing on and that IMO has been a = significant reason for their success: - https://packagist.org/ =20 - https://wordpress.org/plugins/ - https://www.drupal.org/project/project_module = The reason those three have been far more successful has a large amount = to do with the fact that the directory is managed by all the individuals = in the community with solutions to showcase and and not a small group of = overworked and underpaid individuals, and especially not having = gatekeepers who must scan everything and who have subjective approval = for inclusion.=20 And ensuring against bad actors have obviously been effectively managed = by these other projects. Given all those factors I do not see a strong argument to compare the = experience with PECL and PAIR to the idea of php.net = hosting a directory of 3rd party solutions. > (And I think that "minus any objectively determined bad actors" is = hand-waving away some extremely hard non-technical issues.) While I would admit there may be some hand waving there, but to claim = something is "extremely hard" without examples as a justification for = not doing it is even more hand-wavy. Care to delineate at least of few = of those extremely hard non-technical issues you envision to see if they = are indeed extremely hard? >> Or, imagine a store where PHP could sell T-Shirts, plushies and more,=20= >> all to fund more core development? >=20 > I have a hard time imagining that this would ever be more than a = rounding error compared to the sponsorships and individual contributions = that the PHP Foundation currently relies on. Maybe, maybe not.=20 But that perspective obscures the point I was trying to make. It is = entirely possible that soliciting an RFP for a website that could also = help generate revenue would present the community with ideas that nobody = here has even considered. One this is for absolutely certain, though. Keeping the website as-is = will certainly not generate any additional revenue. =20 For me I would rather bet on the potential for innovation than bet = against it. > Frankly, I find your proposal dubious because it assumes that there is = some body of "interested stakeholders" who are going to be able to come = to an agreement on an RFP that can then be used to enable a unbiased, = merit-based selection by a vote of the voting members. Maybe. But there is find fault then it is to find a working solution. =20= What I was asking people to consider is "Would we want this?" If the = answer is yes, they we can discuss those things you claim to be dubious = to see if there are solutions. Again, if we don't look for solution we will absolutely never find any. > It assumes that somehow assembling all of the organizational = infrastructure to enable outsourcing the technical infrastructure is = solving the easy part of the problem. >=20 > It assumes that there is some need for non-static-pages with content = that will somehow come pouring forth out of less-highly-skilled unpaid = volunteers if only the technical infrastructure was taken care of for = them. No, that is not what it assumes.=20 What it assumes is that people can be rallied around an effort that is = aspirational and the outcome can be an order of magnitude better result. = Maintaining the existing website is not aspirational. Empowering the = community to do so much more with the website could be aspirational. =20 So all I was asking was, "Is that a future people would like to see, or = not?" If no, then never mind.=20 But if yes, why can we not explore how to make it happen? -Mike --Apple-Mail=_1EB71F07-6A02-47DB-B790-B542526B5CF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Oct 7, 2024, at 7:31 PM, Jim Winstead <jimw@trainedmonkey.com> wrote:

What is currently = blocking content that at least one unpaid volunteer* wants to contribute = in a way that leverages the existing technical infrastructure is that = there is vague, unwritten policy that we don't mention third-party tools = in the PHP documentation, except for all of the third-party tools that = we already mention in the PHP documentation.

I am = totally with you on this, and I apologize on my part if anything about = what I said made people view it as an either-or proposition. 

Instead, I intended = comments were intended to be viewed as "Yes, and..."


On Sun, Oct 6, 2024, at 12:33 PM, Mike Schinkel = wrote:
IOW, = given that all the current infrastructure really supports are 
static pages = =E2=80=94 without a gargantuan effort to write and maintain a 
custom = framework from scratch by unpaid volunteers =E2=80=94 the resultant 
website can = only realistically be static pages. 

Developing and maintaining the PHP websites is far from a = gargantuan effort, as evidenced by how it is currently (and has long = been) maintained on a very ad-hoc basis by a very small number of = volunteers with some work that is now sponsored by the PHP Foundation. = (I believe that amounts to maybe the equivalent of one full-time = person.)

What = I was thinking when I spoke of a "gargantuan effort" was if a team were = to try to duplicate the functionality of a modern website vs. just = maintaining the aging and minimal website that is currently php.net.  

I think a = proposal for the PHP project taking on something like centralized = databases of "all" third-party packages also needs to come up with a = very good rationale as to why that will turn out differently than how = PEAR and PECL did.

That rationale is an easy one. 

1. First, both PEAR and PECL are package managers. = I was proposing a directory.  Directories are an order of magnitude = easier to manage than a package manager.

2. PECL was an extremely high bar as it was a = package needed to be written in C, so we should just ignore that = one.

3. PEAR had huge friction = because (from what I understand) it required approval from members of = the PEAR Group to be included.

Let's = instead compare to examples that turned out very different from PEAR and = PECL, and although are arguable also package managers it is their = directory aspect that I am focusing on and that IMO has been a = significant reason for their success:

The reason those three have been far more = successful has a large amount to do with the fact that the directory is = managed by all the individuals in the community with solutions to = showcase and and not a small group of overworked and underpaid = individuals, and especially not having gatekeepers who must scan = everything and who have subjective approval for = inclusion. 

And ensuring = against bad actors have obviously been effectively managed by these = other projects.

Given= all those factors I do not see a strong argument to compare the = experience with PECL and PAIR to the idea of php.net hosting a directory of 3rd party = solutions.

(And I think that "minus any objectively determined bad = actors" is hand-waving away some extremely hard non-technical = issues.)

While I would admit there may be some hand waving = there, but to claim something is "extremely hard" without examples as a = justification for not doing it is even more hand-wavy.  Care to = delineate at least of few of those extremely hard non-technical issues = you envision to see if they are indeed extremely hard?

Or, = imagine a store where PHP could sell T-Shirts, plushies and more, 
all to fund = more core development?

I have a hard time imagining = that this would ever be more than a rounding error compared to the = sponsorships and individual contributions that the PHP Foundation = currently relies on.

Maybe, maybe not. 

But that perspective obscures the point I was = trying to make. It is entirely possible that soliciting an RFP for a = website that could also help generate revenue would present the = community with ideas that nobody here has even considered.

One this is for absolutely certain, though. =  Keeping the website as-is will certainly not generate any = additional revenue.  

For me I = would rather bet on the potential for innovation than bet against = it.

Frankly, I = find your proposal dubious because it assumes that there is some body of = "interested stakeholders"  who are going to be able to come to an = agreement on an RFP that can then be used to enable a unbiased, = merit-based selection by a vote of the voting = members.

Maybe.  But = there is find fault then it is to find a working solution. =  

What I was asking people to = consider is "Would we want this?"  If the answer is yes, they we = can discuss those things you claim to be dubious to see if there are = solutions.

Again, if we don't look = for solution we will absolutely never find any.

It = assumes that somehow assembling all of the organizational infrastructure = to enable outsourcing the technical infrastructure is solving the easy = part of the problem.

It assumes that there is some need = for non-static-pages with content that will somehow come pouring forth = out of less-highly-skilled unpaid volunteers if only the technical = infrastructure was taken care of for them.

No, that is not what it assumes. 

What it assumes is = that people  can be rallied around an effort that is aspirational = and the outcome can be an order of magnitude better result. =  Maintaining the existing website is not aspirational. = Empowering the community to do so much more with the website could be = aspirational.  

So all I was asking was, "Is that a future people would = like to see, or not?"  If no, then never = mind. 

But if yes, why can we not explore how to make it = happen?

-Mike

= --Apple-Mail=_1EB71F07-6A02-47DB-B790-B542526B5CF7--