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

De-fork from WPCS #169

Open
jrfnl opened this Issue Jul 28, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@jrfnl
Contributor

jrfnl commented Jul 28, 2018

Follow-on issue for #163.

Action list:

  • Get approval for PR #26 and merge it.
  • Review if any of the other open PRs are nearly ready, if so, fix them up, get approval and merge them.
  • Decide about ruleset name and repo name - see #167.
  • Decide about sniff categories - see #166.
  • Contact GH about getting the repo decoupled.
  • Change the repo name and adjust Packagist if needed.
  • Create a PR feature branch for the decoupling against develop.
    • Cherrypick everything which will be kept from WPCS to an orphan branch.
    • Cherrypick all WPTRT native sniffs to that branch.
    • Add a WPTRTCS specific composer.json file.
    • Add/update typical miscellaneous dev files, such as .gitignore, phpunit.xml.dist etc
    • Rename the WordPress subdirectory to WPThemeReview and update the ruleset documentation (name + description) to match.
    • Move sniffs + tests to their new categories, update the namespaces in the files and update the ruleset to match the new categories.
    • Add applicable use statements to sniffs and where relevant adjust sniff code.
    • Update the @since tags and sniff changelogs in the docblocks of all sniffs which will remain in WPTRTCS.
    • If applicable, remove PHPCS 2.x specific work-arounds, like usage of the WPCS PHPCSHelper class.
    • If necessary, add a WPTRT specific abstract base sniff.
    • Test, test, TEST.
  • Once the PR is merged, open a PR to merge develop into master and tag release 0.1.0. Once the feature branch has been approved, remove the existing develop and master branches, rename the feature branch to develop, create a new master pointing to the same commit and tag release 0.1.0.
  • Change the default PR branch of this repo to develop and remove the theme-review-sniffs branch.
  • Change the PR branch of all open PRs to develop and add a comment in the PR that the PR needs to be rebased and adjusted for the new categories.

[EDIT]

  • Remove the WPCS related release tags.
  • Add the package to Packagist.
@jrfnl

This comment has been minimized.

Show comment
Hide comment
@jrfnl

jrfnl Aug 20, 2018

Contributor

FYI: The detaching of this repo from the WPCS repo in git terms is happening soon.

There are/were 18 forks of the WPCS repo which were based off the TRTCS fork. Those forks will remain attached to this repository and will not revert to being forks of WPCS upstream.

Once the detaching is done, the repo name will be updated as well to make it abundantly clear that this repo is a stand-alone project from that point on-wards.

  • Forks of this repo may want to follow suite and rename their fork to match the new repo name WPThemeReview.
  • If you contribute to both WPCS as well as to this repo, you will need to make a new fork of WPCS.
  • To continue contributing to this repo, no other action is needed, aside from keeping your fork up to date with the state of this repo - which will soon change drastically -. 😎

/cc @carolinan @djrmom @dmtrmrv @ernilambar @Roshanb54 @fervillz @fklein-lu @khacoder @kkoppenhaver @krishna19 @miya0001 @nasabikram @Pross @purevtsooj @RCSWebDev @rinkuyadav999 @sachyya @selul

Contributor

jrfnl commented Aug 20, 2018

FYI: The detaching of this repo from the WPCS repo in git terms is happening soon.

There are/were 18 forks of the WPCS repo which were based off the TRTCS fork. Those forks will remain attached to this repository and will not revert to being forks of WPCS upstream.

Once the detaching is done, the repo name will be updated as well to make it abundantly clear that this repo is a stand-alone project from that point on-wards.

  • Forks of this repo may want to follow suite and rename their fork to match the new repo name WPThemeReview.
  • If you contribute to both WPCS as well as to this repo, you will need to make a new fork of WPCS.
  • To continue contributing to this repo, no other action is needed, aside from keeping your fork up to date with the state of this repo - which will soon change drastically -. 😎

/cc @carolinan @djrmom @dmtrmrv @ernilambar @Roshanb54 @fervillz @fklein-lu @khacoder @kkoppenhaver @krishna19 @miya0001 @nasabikram @Pross @purevtsooj @RCSWebDev @rinkuyadav999 @sachyya @selul

@jrfnl

This comment has been minimized.

Show comment
Hide comment
@jrfnl

jrfnl Aug 20, 2018

Contributor

Create a PR for the decoupling against develop.

For the decoupling, there are two possible ways to go:

  1. Use the WPCS base as is, remove everything we don't need, adjust the things we do.
    This will keep the history intact, but that also means that this repo will have seven years of (irrelevant) WPCS history and the contributors list etc will be heavily skewed towards WPCS contributors.
    I imagine, this will make the threshold to start contributing to this repo higher for new contributors as everything done for this repo before the split will be quite obfuscated.
  2. Start clean.
    What I mean by that is: Deleting the current master and develop branches and creating new virgin orphan branches with those same names. Creating an orphan feature branch, cherrypicking all the commits done for this project + the files from WPCS which we want to keep and adjust. And then pulling the branch with all the cherrypicks to the empty develop branch.
    This would clear out all the old WPCS history - except for the history of the files we are keeping (should be only +/- 8 files) - and give us a clean history with only the commits relevant to this repository and credit to the people who have contributed to the files which will stay in the repository.
    The downside of this is, that it may be confusing for existing contributors that the repo will have changed completely.

The effect of either option on existing pull request is about the same. In both cases, the pull requests will need to be rebased against the new develop anyway and the sniff categories changed, As the open PRs are all either new sniffs - and therefore new files - or changes against files which were new to this repo anyway, the rebase should be relatively painless either way.

@pattonwebz @dingo-d @grappler What do you think ? Have you got a preference ?

Option 1 is the simplest to execute, option 2 would give us a far cleaner base to continue from.

Contributor

jrfnl commented Aug 20, 2018

Create a PR for the decoupling against develop.

For the decoupling, there are two possible ways to go:

  1. Use the WPCS base as is, remove everything we don't need, adjust the things we do.
    This will keep the history intact, but that also means that this repo will have seven years of (irrelevant) WPCS history and the contributors list etc will be heavily skewed towards WPCS contributors.
    I imagine, this will make the threshold to start contributing to this repo higher for new contributors as everything done for this repo before the split will be quite obfuscated.
  2. Start clean.
    What I mean by that is: Deleting the current master and develop branches and creating new virgin orphan branches with those same names. Creating an orphan feature branch, cherrypicking all the commits done for this project + the files from WPCS which we want to keep and adjust. And then pulling the branch with all the cherrypicks to the empty develop branch.
    This would clear out all the old WPCS history - except for the history of the files we are keeping (should be only +/- 8 files) - and give us a clean history with only the commits relevant to this repository and credit to the people who have contributed to the files which will stay in the repository.
    The downside of this is, that it may be confusing for existing contributors that the repo will have changed completely.

The effect of either option on existing pull request is about the same. In both cases, the pull requests will need to be rebased against the new develop anyway and the sniff categories changed, As the open PRs are all either new sniffs - and therefore new files - or changes against files which were new to this repo anyway, the rebase should be relatively painless either way.

@pattonwebz @dingo-d @grappler What do you think ? Have you got a preference ?

Option 1 is the simplest to execute, option 2 would give us a far cleaner base to continue from.

@dingo-d

This comment has been minimized.

Show comment
Hide comment
@dingo-d

dingo-d Aug 20, 2018

Member

As discussed on slack, I'm for option 2

Member

dingo-d commented Aug 20, 2018

As discussed on slack, I'm for option 2

@jrfnl

This comment has been minimized.

Show comment
Hide comment
@jrfnl

jrfnl Sep 16, 2018

Contributor

The branch which is intended to be the new repo content & history, is now online for review: https://github.com/WPTRT/WPThemeReview/tree/feature/163-166-167-169-decouple-from-WPCS

Contributor

jrfnl commented Sep 16, 2018

The branch which is intended to be the new repo content & history, is now online for review: https://github.com/WPTRT/WPThemeReview/tree/feature/163-166-167-169-decouple-from-WPCS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment