Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev > wrote: > > 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, I'm happy that this is noted explicitly! Do we have some of candidate plans that make reviewing experience better? For reviewing, to me, this is the only problem in GitHub. -Yusuke > > Jonathan > WebKit Continuous Integration > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
[Not sure why Apple Mail sent Ryosuke’s replies to the Junk folder but I finally noticed.] > On May 10, 2022, at 3:04 PM, Ryosuke Niwa via webkit-dev > wrote: > > On Tue, May 10, 2022 at 3:01 PM Jonathan Bedard via webkit-dev > wrote: >> >>> On May 10, 2022, at 2:46 PM, Geoffrey Garen 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. > > Just this week, I landed 2~3 patches using a pure Subversion checkout. > It's actually my primary method of landing patches in WebKit right > now. Do you feel like 1 week is not enough time for you to do a git checkout and familiarize yourself enough with GIT to upload patches? Is that the issue? If so, how long do you feel would be reasonable? If you’re not ready to adopt the GitHub workflow for a reason or another, git-svn / bugzilla patches is still a thing and will still work for now. Only committing from pure SVN repositories would go away in a week. > > - R. Niwa > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
On Tue, May 10, 2022 at 3:01 PM Jonathan Bedard via webkit-dev wrote: > > > On May 10, 2022, at 2:46 PM, Geoffrey Garen 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. Just this week, I landed 2~3 patches using a pure Subversion checkout. It's actually my primary method of landing patches in WebKit right now. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
> On May 10, 2022, at 2:46 PM, Geoffrey Garen 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 >> 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@lists.webkit.org >> https://lists.webkit.org/mailman/listinfo/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
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 > 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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
Hi, I think this is a step in the right direction. I hope concerns from other contributors about change log reviews can be addressed in the near future. However, I don’t think it should prevent us from moving away from ChangeLog files, given that commenting on commit logs is still possible in GitHub, although not conveniently. Thanks, > On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev > 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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
I don't think we should this. We haven't even had enough discussions about whether we want to deprecate change logs or not. On Tue, May 10, 2022 at 13:32 Jonathan Bedard via webkit-dev < webkit-dev@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev > -- - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
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@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
