-
Notifications
You must be signed in to change notification settings - Fork 17
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
proposal: add maintainer file #96
Comments
Would rather add a line to the While we're at it, enforcing SPDX license identifiers would be a nice to have. |
I second an additional line at the build file. Idk how others feel about the 2nd line being preserved blank. I think it would fit the purpose here. Should be easily parse able. |
We have |
Does this mean we enforce README files for all community packages?
Sep 1, 2022, 4:35 PM by ***@***.***:
…
We have > README> . I think it's fine place to leave maintainer contacts there.
—
Reply to this email directly, > view it on GitHub <#96 (comment)>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/AEVM3SKED4345SBUSMDTFTLV4EHSVANCNFSM6AAAAAAQCU3F5M>> .
You are receiving this because you commented.> Message ID: > <kiss-community/repo/issues/96/1234752477> @> github> .> com>
|
Unless a package has been contributed via a diff(not a patch) file, no. Anyway, we can always fallback to git. |
miscellanous question: since |
That's actually why kiss has policy of maintainer-only updates. Only maintainer can mess with its own packages. I'm not sure if this policy still stands, but that's how things worked before. |
A seperate maintainer file is useful as it isn't tied to git history. Most people will be cloning with --depth=1 and the author of the last commit shows up as the maintainer for all packages until another commit is pushed for them.
It also allows running bulk operations like changing sources to use/not use VERSION and possibly auto updating packages
The text was updated successfully, but these errors were encountered: