Roland Illig <roland.illig%gmx.de@localhost> writes: > Sure. Since the pkgsrc guide doesn't lose a single word about > COMMIT_MSG, I'll have to look at existing practice instead. I just stuck a few lines in https://pkgsrc.org/wip/users/ : A wip package should have a file COMMIT_MSG that contains exactly the text that should be used if importing the package to main pkgsrc, or in updating the main pkgsrc package from the wip version. Someone with main pkgsrc write access should be able to copy bits and do cvs commit -F COMMIT_MSG. This means that it should start off with "category/pkgpath: Add foo version 1.2.3" and then contain the rest. Or "category/pkgpath: Update foo to 4.5.6", a blank line, a description of packaging changes, and a summary of what upstream should have put in NEWS. > What do you expect pkglint to check? What comes to mind immediately is > that the default placeholders have been replaced. Anything else? I would simply want COMMIT_MSG exists and is non-empty: do nothing COMMIT_MSG does not exist: ERROR that COMMIT_MSG does not exist COMMIT_MSG exists and is empty: ERROR that COMMIT_MSG is empty Actually checking that the content is right is too hard. > Pkglint could also check that the text in COMMIT_MSG corresponds to > DESCR and the other package files. But if COMMIT_MSG can be generated > from the package itself, I don't see any point in having that file at all. It can't be generated for updates. There it has to explain what changed, why patches were dropped, etc. In my view it has to be better than what a developer might commit, because it has to convince somebody like me that a wip committer has thought about every change, and that every dropped patch is intentionally dropped. I do that thinking when I update, and try to comment, but I don't want to commit other people's work without being sure. And, I get a lot of "just change this and it's good" for updates, and that requires chasing down NEWS. Hence my asking for fully completed work for updates.
Description: PGP signature