[webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Geoffrey Garen]

Do I undertand correctly that the proposal here is

	(a) Immediately Deprecate ChangeLogs

	(b) Immediately end support for posting patches from Subversion checkouts?

If so, do you know how many regular WebKit contributors still post patches from Subversion checkouts, and, if that number is not zero, what their schedule is for migrating to git, and whether they need anything from our tools engineers to make that migration smooth?

Seems… problematically forward-looking… to propose immediate migration without that data.

Thanks,
Geoff

> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> A few weeks ago, I started a discussion about deprecating ChangeLogs. In that time, we’ve had more folks using the pull-request workflow and more folks using newer versions of `git` which break automatic ChangeLog rebasing. I propose that on Monday, May 16th, we implement the following policy changes for the WebKit project:
> 
> - Commits no longer require ChangeLogs, they instead require commit messages
> - Commit messages are in the format of `prepare-ChangeLog --no-write`
> 
> Pull-request workflows based on `git-webkit` already support this workflow well, and `git-webkit setup` creates a `prepare-commit-msg` hook that will appropriately format commit messages. In addition, `git format-patch` allows us to create a patch which contains a commit message. This means that contributors still using patch workflows from a git or git-svn checkout will be able to upload compliant patches to bugzilla.
> 
> This will, however, break contributors using pure-Subversion checkouts. This is something that’s going to be happening in the very near future as we deprecate Subversion entirely, so I think this is an acceptable cost in exchange for fully supporting native git workflows.
> 
> The last thing I’d like to note is that a full git-native commit message policy now is something we can modify in the future if we find that reviewing commit messages with “Quote reply” comments is not sufficient, but resolving project disagreements on how or if to address deficiencies in GitHub commit message review don’t seem to be headed towards a resolution quickly.
> 
> Jonathan
> WebKit Continuous Integration
> 
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev