Skip to content

thoughts on churn #22351

@MylesBorins

Description

@MylesBorins

hey all,

I was reading through the contribution guidelines for the git project today and noticed an interesting bit.

Fixing style violations while working on a real change as a
preparatory clean-up step is good, but otherwise avoid useless code
churn for the sake of conforming to the style.

While backporting from master to 8.x, 9.x, and 10.x I've noticed an increase in refactoring that is not supporting a more substantial change in the codebase. These changes have improved the developer experience of node, tightened our style guide, and have quite a number of people more involved in the project.

The churn does have a cost, 8.x in particular has been quite a bit harder to backport too. With 10.x moving to LTS soon and stumbling across the above bit from the git repo, I thought it might be a good idea to weigh the pro's an con's to such a policy and if it something the project may want to adopt.

To be explicit, I am torn. Very interested in other collaborators thoughts here.

Metadata

Metadata

Assignees

No one assigned

    Labels

    discussIssues opened for discussions and feedbacks.metaIssues and PRs related to the general management of the project.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions