[webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Jonathan Bedard]

> On May 10, 2022, at 2:46 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> 
> Do I undertand correctly that the proposal here is
> 
> 	(a) Immediately Deprecate ChangeLogs

Yes

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

We would be immediately ending support for _landing_ patches posted from a Subversion checkout. EWS would continue to accept and test patches posted 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?

We don’t know how many contributors still post patches from Subversion checkouts, and we actually can’t easily answer this question because we’ve had feature parity between Subversion and git-svn checkouts for many years now. There are a few types of changes that aren’t compatible with the patch workflow in general, but those types of changes are a) rare and b) supported in the pull-request workflow

> 
> 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
>