Hi Gabriel, Gabriel Wicki <gabr...@erlikon.ch> writes:
> I actually really liked learning to try to write concise, helpful commit > messages when starting to contribute to Guix. It was probably one of > the steeper parts of the learning curve but also one of the few things > that had a sense of: "Oh, this is what hackers used to do in the olden > days", meaning: doing things the way they make sense. I feel our > documentation (and probably the project in general) has many such > instances of "look: here's how it should have been done all the time", > which enable users to learn and grow, where in the other part of the > digital world people are discouraged to learn things. I know this may > be a highly subjective impression. I felt the same when I started contributing to Guix; I think using a mailing list-based flow for the contributions also gave a hackers' ring to the project, but that doesn't mean it was better. And since we've started embracing modernity and cutting of red tape, why stop at the forge alone? In this perspective, both the GNU ChangeLog style commit messages and the use of two spaces sentencing is more of a hindrance than a real benefit to the project, in my opinion. For trivial package updates that touches just the version string an the origin's hash, I think a summary line alone could do, instead of duplicating it in the commit message, for example. I'm perhaps be a bit wary we'd instead get people to write too much explanatory text in the commit message. GNU ChangeLog, while sometimes tedious to write, is terse when well written. It could be part of the new guidelines: "keep it terse and to the point, using imperative tense". We'd have to come up with a new convention/guideline for commit message, but it could be simplified, and if someone would prefer to continue using the GNU ChangeLog, why not, but it wouldn't be a requirement/consideration in code reviews. For the two spaces sentencing, since it's user-facing (in the documentation and the package descriptions), I don't think it makes sense to change that in Texinfo (which includes package description), but elsewhere we could stop nitpicking about it (in the code comments/docstring/git commit message/etc.) -- Thanks, Maxim
