View in #core on Slack
@Viktor: Due to my daughterās graduation at 11am, I might not be able to participate in the meeting. But I wanted to remind everyone the agenda:
ā¢ Decision how to proceed with core development: 1. Re-fork from v5 or v6. 2. Continue as is with backports. 3. Reduce backports and start developing core on our own, which also means v2.
ā¢ And the other point to discuss, what should we focus on next with full effort: PHP8, jQuery v3, core plugins.
I would suggest leaving directory out of this discussion simply because that work is underway already.
@Tim_Kaye: Is anyone here?
@Simone_Fioravanti: Just for 40 minutesā¦ sorry!
@Tim_Kaye: I donāt think weāll need more than that.
@Viktor: Iām kinda here. It hasnāt started yet.
@Tim_Kaye: I think the first issue, as Viktor, said, is to work out whether a re-fork is a possible way forward. @William_Patton said he was going to look into that.
And just to explain, the Initiativeās Board Meeting is happening at the same time, when Viktor, William, and I are expected to become the new directors.
@Matt_Robinson Do you have a view on re-forking?
OK, no-one wants to chime in on that!
What about PHP8? I think we all know CP has to be made compatible, but itās not that easy, as WP is discovering.
@Matt_Robinson: Just finishing my day job work - be with you in 5 minutes.
@Viktor: William suggested php8 would be easier if we did it without backports
@Tim_Kaye: I can see why he thinks that.
@Viktor: With PHP7 coming to EOL getting to php8 compatibility should be at the top of the list.
@Tim_Kaye: Itās also possible that weāll get more people working on compatibility if we donāt rely on backports. But weāll also get more divergence from WP. Does that matter?
@Viktor: Divergence from WP is one of the topics.
Become more selective with backports.
@Robert_Lilly: I think divergence from WP is going to be inevitable at some point. To me the question is when to make that commitment.
@Namith_Jawahar: +1 for diverging after a final fork
@Joy_Reynolds: It takes a LOT of effort to research and fix all the PHP8 stuff. Thereās no reason to discard that from WP.
@Robert_Lilly: Re: reforking. Are there features in WP 5 or 6 that are desired for CP that would be hard to backport? If so, then reforking may be a better way forward and then commit to divergence.
@Tim_Kaye: Not backporting doesnāt mean not using WPās expertise, @Joy_Reynolds. It just means not always trying to use the same code.
I think the problem with WP 6 and later versions of 5 is that so much of the added code is blocks-related that it requires an awful lot of filtering out before we could use it.
@Simone_Fioravanti: If we āinspireā at a changeset instead of backporting we need to be sure to include similar unit tests, and also not to diverge too much without the need to do so.
@Namith_Jawahar: The final fork can be from before the version they updated the widgets UI
@Joy_Reynolds: There is a list of major features of each WP release pinned to this channel, if you want to lookā¦
@Matt_Robinson: Apologies for my late arrival - in regards to attempting a re-fork of WordPress, I did have a go at this about a month ago. It is my opinion that it is feasible by very hard work and not something we can reasonably accomplish with our current developer base. There are many features not limited to the Block Editor to remove, then the tests that come with those features and there is then the whole build process to unravel that was introduced in wP5.1.
For now, backporting really is not a huge technical challenge with the script we have and multiple backports for a feature are entirely possible. We can then make use of upstream changes relatively easily. One of the largest factors that makes backporting harder work is the current CP code layout. WP did a huge amount of work around coding standards. If we did the same I suspect backporting will create fewer conflicts when it is done.
I should state that I am more than happy to assist anyone willing to learn through the backporting process.
@Tim_Kaye: You seem to have also been working on coding standards, though.
@Laurence: @Viktor and I are working on a video tutorial for backporting.
The CS changes need testing.
Since they are āoneā giant change.
@Matt_Robinson: I have, but in a separate branch from develop and as a proof on concept. It is my hope that early in the 1.5.0 cycle I would like to land a merge for at the very least some spacing changes that can be automatically fixed by the coding standards checks.
And I agree with @Laurence here, once any big change is landed we need a lot more testing to be done by a broader range of users to catch inadvertent issues we introduce.
@Joy_Reynolds: Itās changes like that which make me prefer a refork, since part of what we get from WP is the millions of users testing it.
@Tim_Kaye: By that argument, though, we should refork regularly.
@Joy_Reynolds: No, just the big changes.
@Matt_Robinson: That was my starting thought about re-forking too, however there is so much that needs ripping out that it is a little self-defeating. We cannot only fork parts of WP - itās the whole thing and then remove what we donāt want / need.
@Tim_Kaye: I really donāt see how a refork helps with that, actually, because then weād need a lot of testing of our re-fork. So the problem would remain but in different form.
@Laurence: The other solution is to fix one file at a time with WPCS
@Matt_Robinson: If we want to adopt the ābestā features from WP (however we define ābestā) then backporting is entirely a viable and possible way of doing that.
@Laurence: James seemed to favor the smaller fixes to WPCS. Makes testing easier as we do the same for a backport for example. If we are making changes to a file maybe with a backport. Add a commit that fixes WPCS. Then evalaute.
@Matt_Robinson: Fixing file by file is another option but there are over 1500 files in core alone, and we need to do the files in tests/ too.
@Laurence: It is slow but that is WordPress did. I think that can reduce the testing load for the small number of devs.
If we have 2 approvals required per merge, I am sure we can fix the few files in that PR.
@Matt_Robinson: I am not in favour of entirely separating CP from WP - I think we should continue to utilise the wider developer and testing capacity they have and pull in changes from WP. Especially as I am not a developer my day job and this is more of a hobby project for me.
@Tim_Kaye: I agree with that. I donāt see any point in diverging just to be different.
@Joy_Reynolds: Some have said that is WHY we should diverge.
@Laurence: I hope I didnāt miscommunicate. English is a 2nd language. I agree with the wider base testing.
@Matt_Robinson: If there is a feature that we can add and that is supported by the CP community we can still certainly do that.
@Laurence: I was only suggesting a way to help fix the coding standards with smaller changes at a time.
That is along side the backport or new change.
@Tim_Kaye: Right. It might be that WP has also fixed the formatting of those files in another changeset.
@Matt_Robinson: WP have and the backport is insanely massive.
@Joy_Reynolds: That is the problem. They fixed it in one big change and backporting other things is difficult because CP didnāt.
Since we didnāt follow the same order that they did, itās more complicated.
@Tim_Kaye: Then isnāt Laurenceās suggestion a good one? Fix the files as we do each PR?
@Laurence: We can abstract the challenge as Matt did. One rule fixed at a time. Github actions also make it easier to see the issues.
@Matt_Robinson: On a much smaller scale I have applied coding standards to some plugins I write so I have a little experience. James was always against the automatic fixes, but I have never seen an issue. We could adopt most of those fixes as they are the bigger issue when backporting. We can then amend the rules checked and introduce a rule at a time with the accompanying changes at the same time. But I think the whitespace changes could be landed in a single fix just running the corrections that can automatically be done.
The automatic fixes will fix a whole bunch of rules in one go.
@Tim_Kaye: That sounds fantastic to me.
@Simone_Fioravanti: Agree!
@Matt_Robinson: I am happy to make a PR for this - I will clean up the existing coding standards branches and PRs and create a new PR against develop for the layout changes only in the next week.
@Viktor: I will read everything later, but if someone could summarize what was decided onā¦ that would be helpful.
@Tim_Kaye: No re-fork. Continue with backports, but improve coding standards to make backporting easier and more efficient. This will also help PHP 8 compatibility in future, as weāll be able to use WPās changesets.
@Joy_Reynolds: Is that considered the āroadmapā? How is future direction determined?
@Matt_Robinson: We really have no option but to consider PHP8 as a future path.
@Tim_Kaye: It seems to me we have a short-term āroadmapā and a longer-term one. The short-term one is to test the hell out of v 1.4.2!! The longer one is PHP8 compatibility.
@Matt_Robinson: PHP 7.0 through to 7.3 are all now officially unsupported. 7.4 will be unsupported from the end of November. After this time hosting providers and users will be wanting to move to PHP8.x. CP doesnāt work on PHP8 as things stand so that has to be priority 1, 2 and 3.
@Joy_Reynolds: PHP, not WP?
@Laurence: Borrowing from WP:
ā¢ We might need to remove Yoda check since this is going to be a change upstream.
ā¢ We need to be thinking PHP 9.0 as well.
@Tim_Kaye: Doesnāt āthinking PHP 9ā simply mean paying attention to what is deprecated in PHP 8? Or is there more to that?
@Joy_Reynolds: Since itās a breaking change (8 to 9), it will be more than that.
@Tim_Kaye: Well, removing deprecated stuff is, by definition, a breaking change.
@Matt_Robinson: Yoda checks can be made a warning, along with anything else non-passing. I can pick that up in the PR I make.
With PHP8.x we do need to keep an eye on 9.x as well - PHP seems stalled for years and no it is at the other extreme!
@Joy_Reynolds: To me, they are making PHP worse with every version.
@Matt_Robinson: But it has a bigger number so it must be better - just like WP - right? 
:rolling_on_the_floor_laughing:
@Joy_Reynolds: I was writing in awk the past few days, and itās so similar to how PHP used to beā¦ it was refreshing.
Matt, anything about 1.4.2?
@Matt_Robinson: So far Iāve had no negative feedback about 1.4.2 - Iād like to hear a little more in the positive though!
@Joy_Reynolds: Are you running it on your site?
@Matt_Robinson: Iām running 1.4.2 plus about a dozen other PRs merged in.
@Joy_Reynolds: There isnāt much in 1.4.2, so is the testing time the same as other, bigger releases?
@Matt_Robinson: Only I donāt use the Visual Editor, or play about with themes and widgets a great deal as my site are well established.
@Joy_Reynolds: I went through most of the admin on a wpsandbox site. I think I mentioned the one thing in the editor, which was apparently pre-existing.
@Matt_Robinson: Agreed, a few things dropped out in testing that were already in CP 1.3.1 and are also still in WP 6.1-dev, so wort noting but not for fixing in 1.4.2.
@Simone_Fioravanti: Iāve 1.4.2 on 3 live sites and as now everything ok. About phpmailer seems that @azurecurve have everything ready to release.
@Joy_Reynolds: With WP, there is a release schedule. What do we have as equivalent?
@Tim_Kaye: Itās now over an hour, so thanks to everyone for attending. If you wish to keep discussing things, though, please carry on!
@Joy_Reynolds: My question is really, how do we know when there is āenoughā testing to release?
@Matt_Robinson: Well, I think @Simone_Fioravanti might have just answered that, 3 live sites reported as good plus mine added with some additional testing that only identified issues that were already in the code and not introduced seems good enough for me.
@Joy_Reynolds: Do we need to schedule a meeting where we all test the release, specifically for the things in the release?
@Matt_Robinson: Are we broadly in agreement that 1.4.2 can ship as an official release?
@Joy_Reynolds: I think so. I was merely asking as a general concern for all releases.
Since we donāt use the RC as the main site (and we donāt use our main site much), like WP does, we get very little testing compared to how they do.
Reading WP Slack today, they are seeing a CSS issue in their main menu, caused by a recent unreleased change. So they hop in there and get it fixedā¦
@Robert_Lilly: @Joy_Reynolds Are you suggesting that CP use the release candidate the main site?
@Matt_Robinson: Iām aware they do that, I donāt see how that sets a good image tone for your flagship site to contain glitches, but then if it irons out bugsā¦
@Joy_Reynolds: Iām not suggesting we do the same.
However, we need something to give the RC more actual use.
@Simone_Fioravanti: But as Joy said CP site is not so used.
@Joy_Reynolds: Our new plugin directory will be CP. I donāt know if we could use that, or a separate testing multisite or something like that.
perhaps a testing subdomain of the main site
@Tim_Kaye: I think the main site is going to get revamped. For example, to use multisite. @William_Patton is working on that.
I like the idea of a testing subdomain.
@Joy_Reynolds: but even with a testing subdomain, we have to make a concerted effort to āuseā it
@Tim_Kaye: Indeed.
@Simone_Fioravanti: I always use RC on the (production) site I use developing plugin in and develop in MAMP where I test my plugins.
@Matt_Robinson: Iām still figuring out off of the sites and domains we have and as yet donāt quite have complete access and control. Perhaps we can look to move a site to develop in due course.
My time is at an end for today.
@Laurence: Thanks all.
@Joy_Reynolds: Aside: I started to evaluate a WP fork using a beta tool. I was going along pretty well, but hit a snag and havenāt heard from the dev of the tool. There are a lot of dependencies on previous changes because of how big tasks are done in one commit that touches almost everything. That is what makes it more difficult.
@Viktor: About using RC on live websites. I would be OK with using documentation website to test releases in production. Thatās not as important as main website.