[webkit-dev] ChangeLog Deprecation Plans

Chris Dumez cdumez at apple.com
Fri Apr 22 14:34:29 PDT 2022


I spent some time discussing this offline with Yusuke to better understand his proposal.

It sounds like Yusuke’s proposal is:
1. Have a separate COMMIT_MESSAGE file as part of the PR
2. When the merge queue commits the PR, it uses that COMMIT_MESSAGE content as commit log message and then drops the file from the commit.

I understand that this approach is a bit more flexible for people who like to make multiple commits locally for the same PR. I personally always have a single commit per PR that I keep amending but I think it is good to be flexible.
It also makes reviewing the changelog message a bit easier on GitHub.

I support Yusuke’s proposal. It is a bit more flexible and it still means that separate full/history ChangeLog files would be a thing of the past.

--
 Chris Dumez




> On Apr 22, 2022, at 2:10 PM, Chris Dumez via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> I am strongly in favor of dropping the ChangeLog files and relying on the GIT commit message instead. Not having to update ChangeLog files was actually a big motivator for me to switch to GitHub, as I thought until now we didn’t have to update ChangeLog files when switching Github PRs.
> 
> With the provided GIT commit hook, the changelog format is identical to what we had in the ChangeLog files anyway. I don’t understand (yet) the need for having the same message in two separate location.
> 
> Git commit logs don’t roll over (like ChangeLog files do), they are searchable, they have the same format (you CAN add inline comments on a per-file basis for e.g.). They are also easily modifiable from the GitHub interface.
> 
> I will also note that ChangeLog files are a frequent source of conflicts when using GIT. Yes, we do have a resolve-ChangeLogs script that’s supposed to help with that. However, please note that this script hasn’t work reliably for quite a while (at least for many of us at Apple with very recent SDKs).
> ChangeLog entries no longer show on top when rebasing, meaning I have to move them back on top manually. Worse, if I fail to notice and use `webkit-patch upload`, it will upload to the wrong bugzilla bug.
> 
> If people really still want to maintain separate ChangeLog files, I am hoping this can be generated from my commit messages and done automatically for me upon committing. I really don’t want that as part of my patch/PR.
> 
> --
>  Chris Dumez
> 
> 
> 
> 
>> On Apr 19, 2022, at 11:00 AM, Geoffrey Garen via webkit-dev <webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>> wrote:
>> 
>>>> Commit message is tied to a commit, so editing commit without breaking commit-message is hard (how to revert one change from one commit without rewriting commit message? It requires some git hack). Separate independent COMMIT_MESSAGE file can solve this problem and makes local development easy.
>>> 
>>> Developers who are used to git -- which nowadays is pretty much everyone except WebKit devs -- are also used to rewriting commit messages.
>> 
>> I think it’s important for WebKit's git transition to take consideration of WebKit developers and WebKit workflows. I hope we can agree on this premise as we discuss various options for commit messages.
>> 
>> Thanks,
>> Geoff
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220422/9c1767e3/attachment.htm>


More information about the webkit-dev mailing list