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

mangler: allow configuring copyright year behaviour (and possibly author) via editorconfig #128

Open
thesamesam opened this issue Mar 24, 2023 · 2 comments

Comments

@thesamesam
Copy link
Member

thesamesam commented Mar 24, 2023

Right now, we only do copyright year updating in pkgdev commit for the Gentoo repository, but it can be useful in other repositories. We could make it configurable both for year and possibly the line ("Gentoo Authors" or something else).

See also #11. I'm not sure if this belongs in a metadata/ file or in .editorconfig. I think it might be a good fit for the latter.

See also #127.

@antecrescent
Copy link
Contributor

Right now, we only do copyright year updating in pkgdev commit for the Gentoo repository, but it can be useful in other repositories.

I agree. Also Gentoo Foundation -> Gentoo Authors updating should be available to other official Gentoo repositories as well. In particular, I'm thinking of GURU here, which generally does not get merged into ::gentoo and where contributors occasionally push ebuilds with Gentoo Foundation copyright notices.

See also #11. I'm not sure if this belongs in a metadata/ file or in .editorconfig.

I don't see how EditorConfig is the right tool for this. None of the supported k-v pairs allow specifying a copyright template.

antecrescent referenced this issue in gentoo/guru Jun 12, 2024
@thesamesam
Copy link
Member Author

The spec has:

EditorConfig cores shall accept and report all syntactically valid key-value pairs, even if the key is not defined in this specification.
EditorConfig plugins shall ignore unrecognized keys and invalid/unsupported values.

editorconfig k/vs can be extended although there's no extension namespace (so no prefix which is reserved for extensions).

It feels like a decent fit, but I don't insist on us using it.

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

No branches or pull requests

2 participants