Thank you for your feedback Eric.
Hello Mario,
On 6/15/21 12:41 PM, Mario Loriedo wrote:
> As mentioned during yesterday's community call we should have a
> discussion about conventional commits [1] to decide if we should enforce
> it or not.
>
> Currently a PR check verifies if commits messages follow the convention.
> PRs can be merged even if the check fails. But we need to decide if we
> are going to enforce the convention (block PRs where the check fails,
> update the contribution guide etc...) or remove the PR check and
> let contributors free to use any commit message format they like.
>
> What's your thoughts?
>
> [1] https://www.conventionalcommits.org/
> <https://www.conventionalcommits.org/>
I'd prefer it if we didn't police commit message titles. There isn't
really a functional difference between "Remap redhat/java plugin to
point to java8" versus "fix(plugins): remap redhat/java to point to java8".
Believe it makes a difference when you need to rapidly figure out the context of 60 PRs. Every Tuesday we do a review of the PRs that have been merged last week with Florent and David H. And there is no doubt that the more PR titles use conventional commits the quicker the review will be.
For my understanding: why do you need to review all the merged PRs?
Do we have a big divergence between planned and implemented tasks?
If we're proposing this as a way to generate the changelog then I'd
caution against that. It is generally considered bad form to dump
commits into a file and call it a changelog. [1] Instead I would suggest
we have a small markdown file in which developers can document
meaningful changes near release time. In GNU projects this is the NEWS
file, or for example Eclipse's Release Notes document. [2]
There is no plan to generate a changelog. Today conventional commits help in the release notes preparation process because it's easier to extract the noteworthy issues from last week's commits.
I don't think we need a changelog but we need better release notes. Your NEWS file proposal is an interesting one and we could generate that using a query like this one [1]. But that may be out of the scope of this thread.
If we need a good source for release notes - can we consider writing (not generating) changeslog/NEWS/whatever_we call_it (as Eric proposed) as an alternative to generating log with Conventional commits?
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
