[webkit-dev] ChangeLog Deprecation Plans
rniwa at webkit.org
Mon Apr 18 13:35:02 PDT 2022
On Mon, Apr 18, 2022 at 13:34 Ryosuke Niwa <rniwa at webkit.org> wrote:
> On Mon, Apr 18, 2022 at 08:30 Jonathan Bedard via webkit-dev <
> webkit-dev at lists.webkit.org> wrote:
>> As we migrate WebKit from Subversion to git, I would like to migrate the
>> project away from ChangeLogs. The reason for this is that ChangeLogs make
>> some of the features of git hard to use, namely, cherry-picking commits
>> between branches requires conflict resolution every time. Rotating
>> ChangeLogs is also moderately difficult in git with locked down commit
>> access like our project has, only repository administers would, in
>> practice, be able to rotate ChangeLogs. Lastly, ChangeLogs are uncommon in
>> git based projects, so new contributors will find them difficult to manage.
>> Currently, our git tooling makes very little effort to either support
>> ChangeLogs or to provide alternatives. I have listed bellow some of the
>> reasons I understand folks to like ChangeLogs along with possible git-based
>> solutions, if necessary.
>> 1) Subversion commit messages are stored server side, local development
>> needs a copy
>> git doesn’t have this problem. We have a local record of commit messages
>> in every checkout.
>> 2) We need a way to comment on commit messages in review
>> Current tooling sets the pull request description as the commit message,
>> “Quote Reply” kind of provides a way to inline comment, although it’s not
>> the formal review UI
>> *Proposal*: Tooling should support a “COMMIT_MESSAGE” file in each pull
>> request commit that becomes COMMIT_MESSAGE when a pull request is landed
>> 3) Edit commit messages while creating a change, not just when committing
>> the change
>> The “overwrite” workflow already sort of support this idea by using amend
>> commits instead of appending commits to an existing branch
>> *Proposal*: The above “COMMIT_MESSAGE” file workflow would allow
>> iterative building of a commit message before committing
> There is another issue to add here. Right now, change log entry exists for
> many sub directories of the respiratory like Source/WebCore and
> LayoutTests. With a commit message, however, there could be only one per
> patch / PR.
> This makes it harder to review each part separately. For example, I'd like
> to focus on core changes first and then onto test changes, or vice versa
> depending on patches I'm reviewing.
> So ideally, this commit message field mirror where change log files
> currently exist such that "commit message" for each sub directory will show
> up separately.
> 4) Using git commands to view commit messages is hard
>> There don’t seem to be many projects which have a solution for this. In
>> practice, it seems that reducing the scope of messages shown by restricting
>> history to a specific directory or even file is one solution, another is
>> shorter commit messages
>> *Proposal*: Have Tools/Scripts/git-webkit setup configure hooks in
>> contributors local git repositories to lay down CommitMessages.history
>> files on merge, checkout and commit which contain the last 5000 commit
>> messages. We can put these in similar places to where ChangeLogs are today,
>> although we would likely want them in fewer places because this will
>> increase local compute time on many git operations. We could also make this
>> a configurable setting so that engineers who are more comfortable with the
>> raw command line tooling do not have to deal with slower git operations.
>> I like the COMMIT_MESSAGE and hooks proposals because they are opt-in.
>> Contributors who wish to use native git tooling to contribute and interact
>> with the project do not have to use either tool, but the tools are
>> compatible enough with native git workflows that contributors who find
>> editing and viewing commit messages primarily in a text editor
>> Looking forward to the discussion,
>> Jonathan Bedard
>> WebKit Continuous Integration
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
> - R. Niwa
- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev