Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The Future of PHP_CodeSniffer #3932

Open
jrfnl opened this issue Dec 1, 2023 · 58 comments
Open

The Future of PHP_CodeSniffer #3932

jrfnl opened this issue Dec 1, 2023 · 58 comments

Comments

@jrfnl
Copy link
Contributor

jrfnl commented Dec 1, 2023

TL;DR: This repo is being abandoned. The project continues in the PHPCSStandards organisation.


Okay, it's time.

About seven months ago, I was given commit access to this repository. At that time, @gsherwood and me had a call and the agreement was that we'd work together through the back log and get 3.8.0 released, which would give me the chance to get insight into his process, the release process and to verify that we were aligned in vision for the future for the repository.
This agreement included, at my insistence, the provision that I would not merge my own PRs and that Greg would preferably also work via PRs for his contributions.

This started off well and I made a plan with a priority-list for which PRs to merge in which order, made lists with on-going and future projects etc and we had two calls in May this year, but I think most of you who have followed the repo closely will have noticed that it ended there.

I'd been trying to get a response, any kind of response, from Greg since beginning of June and have been sending pings at regular intervals with little effect, aside from one short "sorry, no sight on availability" in July.

A few of weeks ago, I have finally received a, just as short, response which basically said that Greg will abandon the project.

image

I very much respect Greg's decision and would like to thank him for all his tireless work and the years and years he has maintained this package for the benefit of the wider PHP community. He is a true open source hero and I wish him all the best.

Having said that, this is where we are now:

  • I only have commit, not admin access to the repo.
  • I don't have insight in the release process nor access to PEAR or Packagist for this repo.

With that in mind, I asked Greg to transfer the repository to the PHPCSStandards organisation, which would give me full control.
I also asked him to give me access to Packagist and PEAR.
This would allow for keeping the package in PEAR and Packagist under its current name and should make for a smooth transition for end-users.

Unfortunately, Greg came back to me a week later and conveyed that the Squizlabs company has declined to transfer the repository stating "code ownership" as the reason.

Well, so be it. 🤷

I have now forked the repo to the PHPCSStandards organisation, and spend some time to get it up & running properly and I have registered the repo under the name phpcsstandards/php_codesniffer on Packagist.
Update: The Composer/Packagist name will stay the same.

This is less than ideal as all of the 200.000+ packages which have a dependency on PHP_CodeSniffer will need to update their workflow/composer.json/PHIVE etc.
It means losing all open PRs (with the exception of my own, which I've recreated). It means losing all issues, having to recreate the wiki etc etc.
And even when this repo will be officially marked as abandoned with the PHPCSStandards version marked as its replacement, it still means that the majority of users, who don't watch the repo, will be left to their own devices to figure this out.

So here we are.

For the time being (for as long as I am the sole maintainer), I will merge my own PRs and I will work on getting 3.8.0 released as soon as possible.
As I don't have access to PEAR, nor insight in how to release to PEAR, it will mean dropping support for installations via PEAR straight away. (note: this does not affect the PEAR sniffs)
Support for installation via Composer, PHIVE, PHAR downloads and git clones will continue, though will all undergo name/address changes.

Note: I would recommend waiting to make the switch until the 3.8.0 release has been tagged. Watch releases on the new repo to automatically get notified of this. The changelog will contain the relevant information for making the switch.

It also means that version 4.0 will be released sooner rather than later and that I will automate as much as possible of the release process to allow for more rapid releases.

Going forward, there are plenty of things I would like to improve, both to enhance the end-user experience, as well as to enhance the dev experience for maintainers of external standards. I also have a list of things in mind to try and make the repo more maintainable and make contributing more straight forward.

I have far more ideas than I have time, so I will need help and more importantly, the project will need significant funding, as the amount of work I see ahead of me would leave very little time for paid work, especially considering I also maintain a fair number of the external standards build on top of PHP_CodeSniffer.

I am posting this here in the spirit of openness and I am hopeful that you all will support me in this, both with quality contributions as well as by getting your employers/all those companies which use PHP_CodeSniffer to fund continued maintenance of the project.

Once the dust settles, I will announce more detailed plans for the future and a roadmap for future releases.

In the mean time, please bear with me. I currently still have quite a few other outstanding commitments, so it will take some time before I can free myself up sufficiently, but the repo is open for issues and PRs.

Please note: funding for this project is not a suggestion, but a requirement to safeguard the future of this project and allow for growing the maintainer pool. Without funding, I will not be able to dedicate the time needed to the project, both to move it forward, as well as to coach others to become co-maintainers.
If you want to help, here are channels through which this project can receive funds:

If you support me in this, you can indicate this via a 👍 and by getting companies using PHP_CodeSniffer to start funding the project.

If you have any concerns about all this, please raise them by leaving a comment.

And if you have suggestions on how to make the switch-over experience smoother for end-users, please open an issue in the new repo.

Other than that, please join me in thanking @gsherwood for all the years he's kept this project going!

Oh and give @PHP_CodeSniffer on X or @phpcs on Mastodon a follow if you'd like to stay informed.

P.S.: In the interest of transparency, I have so far only merged maintenance related PRs in the new repo. Now this announcement is out, I will start merging functional PRs over the next few days or so.

/cc @kukulich @wimg @weierophinney @GaryJones @dingo-d @klausi @photodude @Potherca @webimpress @fredden @michalbundyra @sirbrillig @othercorey @greg0ire @dereuromark @umherirrender @stronk7 @Ocramius

@jrfnl jrfnl pinned this issue Dec 1, 2023
jrfnl added a commit to jrfnl/phar.io that referenced this issue Dec 1, 2023
The maintainer of PHPCS/PHPCBF has indicated they are abandoning the package.

The repo has now been forked and will continue to be maintained in the new location.

Ref:
* squizlabs/PHP_CodeSniffer#3932
@theofidry
Copy link

Unfortunately, Greg came back to me a week later and conveyed that the Squizlabs company has declined to transfer the repository stating "code ownership" as the reason.

Would it be possible to mark the package as abandoned from Packagist's side to suggest phpcsstandards/php_codesniffer instead?

@jrfnl
Copy link
Contributor Author

jrfnl commented Dec 1, 2023

Unfortunately, Greg came back to me a week later and conveyed that the Squizlabs company has declined to transfer the repository stating "code ownership" as the reason.

Would it be possible to mark the package as abandoned from Packagist's side to suggest phpcsstandards/php_codesniffer instead?

@theofidry See PR #3933

@theseer
Copy link

theseer commented Dec 1, 2023

As @jrfnl already created a PR to update the phive alias for easy installation, I just wanted to let everybody here know we - as the phar.io / phive team - will be merging the change as soon as there's an official confirmation, for instance by a comment here by @gsherwood or via approval on the PR on our site (phar-io/phar.io#143).

@slaFFik
Copy link

slaFFik commented Dec 1, 2023

Thank you for the detailed explanation, very much appreciated.

@jrfnl I think it's possible to migrate all issues using this script https://gist.github.com/slaFFik/e1593c6597f11bb7c4dd5122f7f04de9

You will need to recreate all the labels manually to assign labels in a new place properly and automatically.
But issues will be removed in the current repo, so maybe adjustments are needed to just "create", not "transfer" (docs).

@jrfnl
Copy link
Contributor Author

jrfnl commented Dec 1, 2023

Thank you for the detailed explanation, very much appreciated.

@jrfnl I think it's possible to migrate all issues using this script https://gist.github.com/slaFFik/e1593c6597f11bb7c4dd5122f7f04de9

You will need to recreate all the labels manually to assign labels in a new place properly and automatically. But issues will be removed in the current repo, so maybe adjustments are needed to just "create", not "transfer" (docs).

@slaFFik Thanks for that suggestion. Looks useful, though I don't think I will use it. While it is nice to have the issue history, it is also nice to start with a clean slate. There are lots of open issues here and quite some are stale and possibly no longer relevant, so I think I'll leave it up to the original reporters to transfer over their own issues if still relevant. (and I'll nudge in various open issues/PRs when I think the issue definitely is still relevant).

@ravage84
Copy link

ravage84 commented Dec 1, 2023

@jrfnl thank you for your transparency and your effort, already.

Though, I hope the whole affair could be resolved differently, I can relate to your situation, as I was in a similar one with PHP Depend & PHP Mess Detector myself four years ago.

As for the funding, I can recommend you the following:

Further options for funding I know of (not tested myself, though):

Also, as a little jump start, I will nominate you for my emlpoyer's symbolic ~50 USD one time FOSS donation. We wanted to donate to Greg in the past but that never panned out.

As for the issues, as long as the old repos keeps available, I also recommend you to do a fresh start in the new repo.

One last thing:
Back in 2019, instead of trying to maintain those projects myself, I contacted all of the most active contributors of the two projects and asked them if they wanted to join a new maintainer team.
Quite a few joined and some of them stayed and maintain the prroject to this day.

All the best from Switzerland.

@derrabus
Copy link

derrabus commented Dec 1, 2023

Thank you very much for keeping this project alive, @jrfnl!

@aldavigdis
Copy link

I don't want to step on anyone's feet here, so I'll ask here first:

Are there any plans to update wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer and phpcompatibility/phpcompatibility-wp to account for the move?

@CiderAndWhisky
Copy link

Thank you for all the effort you put into this, @jrfnl! Happy to be contributor nr. 2 - someone beat me on the way :-(

@ldebrouwer
Copy link

@jrfnl I just wanted to chime in, and say that you’re an absolute star. Thank you for everything you do for this community, and your continued transparency around it.

@jrfnl
Copy link
Contributor Author

jrfnl commented Dec 1, 2023

I don't want to step on anyone's feet here, so I'll ask here first:

Are there any plans to update wp-coding-standards/wpcs, dealerdirect/phpcodesniffer-composer-installer and phpcompatibility/phpcompatibility-wp to account for the move?

@aldavigdis I have branches ready to update all of those (basically for all external standards I'm actively involved in). Still currently working through my "post announce" action list (which is long) while also responding to all the messages coming in.

Still, there are plenty more external standards for which I don't have PRs ready, so any of those you could help, would be great ;-)

@tm1000
Copy link

tm1000 commented Dec 1, 2023

@jrfnl my CTO just alerted me to this thread. Thank you for your contributions. I'm going to move my one or two unmerged PRs from last year that you helped me review into your repository and convert my company's repositories to use the fork

Aside from that I'm committed to helping you get funding as well

Thank you for taking charge and thank you for being so committed to helping all of us that have committed PRs even when you didn't have merge/commit access.

You are a superstar. Wish this would have happened sooner but glad it happened at all.

@mbomb007
Copy link

Could you add a note to the README of the squizlabs project? At the moment, you have to view the issue page to see the post about the new project.

@jrfnl
Copy link
Contributor Author

jrfnl commented Jan 17, 2024

@mbomb007 There is a PR open for that: #3933

jrfnl added a commit to jrfnl/php-the-right-way that referenced this issue Feb 12, 2024
... and small improvement to the text about running PHPCS in a git hook.

_When this text was originally written, the `--filter=GitStaged` option didn't exist yet, but now it does, it seems like a good pointer to add to the text._

Ref:
* squizlabs/PHP_CodeSniffer#3932 (about the repo URL change)
* squizlabs/PHP_CodeSniffer#2137 (about the GitStaged filter)
nazares added a commit to nazares/php-the-right-way that referenced this issue Feb 17, 2024
... and small improvement to the text about running PHPCS in a git hook.

_When this text was originally written, the `--filter=GitStaged` option didn't exist yet, but now it does, it seems like a good pointer to add to the text._

Ref:
* squizlabs/PHP_CodeSniffer#3932 (about the repo URL change)
* squizlabs/PHP_CodeSniffer#2137 (about the GitStaged filter)
jrfnl added a commit to jrfnl/phpqa.github.io that referenced this issue Apr 15, 2024
PHP_CodeSniffer is under new management. See: squizlabs/PHP_CodeSniffer#3932

Also note that installation via PEAR is no longer supported.
LeSuisse added a commit to Enalean/tuleap that referenced this issue Apr 16, 2024
Changes:
https://github.com/PHPCSStandards/PHP_CodeSniffer/blob/3.9.1/CHANGELOG.md

This includes a move to the new supported fork, see
squizlabs/PHP_CodeSniffer#3932

Part of request #36864: Run Tuleap with PHP 8.3

Change-Id: I209d7a27139f1ea57b623f2309b27ec382964567
DannyvdSluijs pushed a commit to DannyvdSluijs/PHP_CodeSniffer_Continuation that referenced this issue Apr 29, 2024
⚠️ **_To be merged once the Packagist edit has been made._** ⚠️

This reverts commit f6dc841 and updates the information in the changelog for the 3.8.0 release.

**Users who already changed the package name in _their_ `composer.json` dependencies, should switch back to the original package name.**

Refs:
* See [the conversation from this comment down](squizlabs/PHP_CodeSniffer#3932 (comment)).

Closes 113, 114
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests