Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
I’m measuring from “engineer tells GitHub to land a change”, not “Merge-Queue checks out the change”. The basic steps of the process are: - GitHub sends hook to buildbot - buildbot validates hook and PR - buildbot checks out PR - buildbot inserts reviewer to commit message and ChangeLog - buildbot runs basic pre-commit checks - buildbot adds identifier - buildbot commits - buildbot updates PR with landed commit - buidbot comments on PR and bug with information on landed commit - buildbot closes associated bug The “commit” step usually happens at 2 minute mark currently, I gave the time for the whole process (including bug comments, bug closing, etc). It will be a bit faster once we can drop the `git-svn` pieces of this, it’s the “checkout” and “add identifier” step that can take longer than you would expect. 10 minutes is a worst-case scenario when there are already other changes in the unsafe queue and some bots are busy with Merge-Queue and Commit-Queue requests, so there is only a single available bot serving the unsafe queue. Jonathan > On May 11, 2022, at 4:31 PM, Chris Dumez wrote: > > >> On May 11, 2022, at 11:56 AM, Jonathan Bedard via webkit-dev >> wrote: >> >> Trying to embed previous replies is going to get messy, will be referencing >> those replies but not embedding them. >> >> Unsafe-Merge-Queue should be very fast, I haven’t seen anything take longer >> than 10 minutes from label application to landing or rejection. The average >> case is 3-4 minutes. We’re aware of what the architectural problem with >> Commit-Queue is that slows down the fast path, Unsafe-Merge-Queue has fixed >> that. The solution we used isn’t transferable to Commit-Queue. > > I personally don’t think that delaying a critical build fix / gardening by 10 > minutes is OK. It’s called “unsafe-merge-queue”, why does it take this long > to commit? Why isn't it as fast as "generate a unique identifier and git > push”? > Sure, I have no idea how the unsafe-merge-queue does but it is hard for me to > imagine it should take more than 1 minute given what it needs to do and given > that it should need to do extremely little testing given that it is “unsafe”. > > 4 to 10 minutes is nowhere near as fast as `git svn dcommit` and is therefore > a pretty large regression. ___ 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 11, 2022, at 11:56 AM, Jonathan Bedard via webkit-dev > wrote: > > Trying to embed previous replies is going to get messy, will be referencing > those replies but not embedding them. > > Unsafe-Merge-Queue should be very fast, I haven’t seen anything take longer > than 10 minutes from label application to landing or rejection. The average > case is 3-4 minutes. We’re aware of what the architectural problem with > Commit-Queue is that slows down the fast path, Unsafe-Merge-Queue has fixed > that. The solution we used isn’t transferable to Commit-Queue. I personally don’t think that delaying a critical build fix / gardening by 10 minutes is OK. It’s called “unsafe-merge-queue”, why does it take this long to commit? Why isn't it as fast as "generate a unique identifier and git push”? Sure, I have no idea how the unsafe-merge-queue does but it is hard for me to imagine it should take more than 1 minute given what it needs to do and given that it should need to do extremely little testing given that it is “unsafe”. 4 to 10 minutes is nowhere near as fast as `git svn dcommit` and is therefore a pretty large regression. ___ 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
Trying to embed previous replies is going to get messy, will be referencing those replies but not embedding them. Unsafe-Merge-Queue should be very fast, I haven’t seen anything take longer than 10 minutes from label application to landing or rejection. The average case is 3-4 minutes. We’re aware of what the architectural problem with Commit-Queue is that slows down the fast path, Unsafe-Merge-Queue has fixed that. The solution we used isn’t transferable to Commit-Queue. Manual landing from a Subversion checkout isn’t broken by this proposal (although that is coming very soon), but it will be made much more painful. In my response to Geoff, I said: We would be immediately ending support for _landing_ patches posted from a Subversion checkout This is a deliberately narrow statement. Because SVN doesn’t have local commit messages, we can’t generate (or apply) patches containing commit messages. You can still land from a raw Subversion checkout, but you would need to manually draft a compliant commit message. `git svn dcommit` from a git-svn checkout is also unaffected (and what Commit-Queue and Merge-Queue are using and will continue to use) because git checkouts can apply patches with commit messages. To R. Niwa’s point that he would “never want to make a local commit”, that’s not going to be possible in the very near future, and there isn’t much we can do tooling wise to change this fact. As mentioned in my initial email, discussions around placing commit messages in files prior to merge for review don’t seem to be headed towards a resolution quickly, and the active harm ChangeLogs are causing to development is making their deprecation more urgent than the aforementioned discussion would seem to be resolving. Lastly, Chris did mention this, but just to confirm what he said, GitHub checkouts can use `git svn` too, there are a few more “yes, buts” to it (`git svn rebase` is to be avoided), as Chris mentioned, `git-webkit setup-git-svn` does work in GitHub checkouts. ___ 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 Wed, May 11, 2022 at 08:12 Chris Dumez wrote: > > On May 11, 2022, at 12:13 AM, Ryosuke Niwa via webkit-dev < > webkit-dev@lists.webkit.org> wrote: > > On Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa wrote: > > > > On Tue, May 10, 2022 at 20:36 Chris Dumez wrote: > > > [Not sure why Apple Mail sent Ryosuke’s replies to the Junk folder but I > finally noticed.] > > > > It's something to do with @webkit.org not being able to send a proper > sender ID due to it being a forwarding address. > > On May 10, 2022, at 3:04 PM, Ryosuke Niwa via webkit-dev < > webkit-dev@lists.webkit.org> 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? > > > > I already have GitHub clones. The issue I have is with committing > directly. I need to be able to commit directly as is since commit queue > even fast one is simply way too slow. > > > I agree that the fast-cq is a lie and is way slower than committing > manually (and usually not by a little). I haven’t tried the > unsafe-merge-queue in GitHub yet but I hope it is much faster than fast-cq > was. If unsafe-merge-queue is not nearly as fast as a manual commit then > I think it needs to be fixed. > Given that the plan of record is that nobody has direct commit access to > the GIT repo and the only way to land a build fix or test gardening will be > via the merge queue, I think it is critical. > I agree. I’ll note though that IMO, there are some very specific cases for when > extremely fast commit is required. Namely, build fixes and tests gardening, > to get the tree / bots in a sane state as soon as possible and keep things > running smoothly. For other kind of changes, I personally think they should > go through rigorous EWS testing and merge queue. > Or you're making changes to things like introduction.md or perf dashboard code, which has zero change of breaking WebKit builds or tests. That said, the speed of the commit queue and EWS has been going downhill > and this is less and less practical IMO. The main reason for this seems to > be that some tests are most of the time either plain failing or flaky on > EWS, making processing much slower because the bot has to retry each patch. > This can hopefully be addressed with much stricter / aggressive gardening / > sheriffing. > > > 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. > > > > Well, that's precisely my use case. I don't even write a patch in a pure > Subversion checkout anymore these days. > > > Ok, seems like you are using GitHub checkouts for writing the patch and > then separate Subversion checkout to commit the patch. I find it a bit > surprising given that GitHub checkouts can still commit to SVN directly via > git-svn (`git-webkit setup-git-svn` to set up as per > https://github.com/WebKit/WebKit/wiki/Contributing#checking-out-WebKit). > Jonathan only mentioned that commits from pure SVN checkouts would be > broken. He didn’t say anything about commits from git-svn checkouts so I > assume those would still work (and should be more convenient for you?). > @Jonathan, please correct me if I’m wrong. > My main issue is that I never want to make a local commit because it messes with my branch states. Has the solution to use a separate file to write commit message been implemented yet? I only want to commit something when it's getting merged into the remote main. - R. Niwa -- - 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 11, 2022, at 12:13 AM, Ryosuke Niwa via webkit-dev > wrote: > > On Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa wrote: >> >> >> On Tue, May 10, 2022 at 20:36 Chris Dumez wrote: >>> >>> [Not sure why Apple Mail sent Ryosuke’s replies to the Junk folder but I >>> finally noticed.] >> >> >> It's something to do with @webkit.org not being able to send a proper sender >> ID due to it being a forwarding address. >> >>> 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? >> >> >> I already have GitHub clones. The issue I have is with committing directly. >> I need to be able to commit directly as is since commit queue even fast one >> is simply way too slow. I agree that the fast-cq is a lie and is way slower than committing manually (and usually not by a little). I haven’t tried the unsafe-merge-queue in GitHub yet but I hope it is much faster than fast-cq was. If unsafe-merge-queue is not nearly as fast as a manual commit then I think it needs to be fixed. Given that the plan of record is that nobody has direct commit access to the GIT repo and the only way to land a build fix or test gardening will be via the merge queue, I think it is critical. I’ll note though that IMO, there are some very specific cases for when extremely fast commit is required. Namely, build fixes and tests gardening, to get the tree / bots in a sane state as soon as possible and keep things running smoothly. For other kind of changes, I personally think they should go through rigorous EWS testing and merge queue. That said, the speed of the commit queue and EWS has been going downhill and this is less and less practical IMO. The main reason for this seems to be that some tests are most of the time either plain failing or flaky on EWS, making processing much slower because the bot has to retry each patch. This can hopefully be addressed with much stricter / aggressive gardening / sheriffing. >> >>> 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. >> >> >> Well, that's precisely my use case. I don't even write a patch in a pure >> Subversion checkout anymore these days. >> Ok, seems like you are using GitHub checkouts for writing the patch and then separate Subversion checkout to commit the patch. I find it a bit surprising given that GitHub checkouts can still commit to SVN directly via git-svn (`git-webkit setup-git-svn` to set up as per https://github.com/WebKit/WebKit/wiki/Contributing#checking-out-WebKit). Jonathan only mentioned that commits from pure SVN checkouts would be broken. He didn’t say anything about commits from git-svn checkouts so I assume those would still work (and should be more convenient for you?). @Jonathan, please correct me if I’m wrong. >> - R. Niwa >> >> -- >> - 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 Wed, May 11 2022 at 12:16:46 AM -0700, Ryosuke Niwa via webkit-dev wrote: No, I'm using Github clones to write patches then using Subversion checkout to commit those patches. If you use the old git repo via git-svn, not the GitHub repo, then you can use 'git svn dcommit'. ___ 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
Another idea (not formally proposing): Safari extension to bring Bugzilla's good points to GitHub UI. I tried writing random userscripts, and while threaded comments for commit message / conversation view while reviewing are still missing, I got some UI to make comment on commit message easier while reviewing. Good thing is that we can bring interesting things to GitHub without changing underlying protocol much. Bad thing is it can be fragile. Anyway, I hope we can have a solution :) -Yusuke > On May 10, 2022, at 8:50 PM, Yusuke Suzuki via webkit-dev > wrote: > > > >> 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 ___ 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 10:04 PM Chris Dumez wrote: > > On May 10, 2022, at 9:27 PM, Ryosuke Niwa wrote: >> >> Well, that's precisely my use case. I don't even write a patch in a pure >> Subversion checkout anymore these days. > > Also, I didn’t fully understand this comment. Did you mean that you are > already using git-svn and relying to `git-svn dcommit` for local committing? No, I'm using Github clones to write patches then using Subversion checkout to commit those patches. - 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 Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa wrote: > > > On Tue, May 10, 2022 at 20:36 Chris Dumez wrote: >> >> [Not sure why Apple Mail sent Ryosuke’s replies to the Junk folder but I >> finally noticed.] > > > It's something to do with @webkit.org not being able to send a proper sender > ID due to it being a forwarding address. > >> 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? > > > I already have GitHub clones. The issue I have is with committing directly. I > need to be able to commit directly as is since commit queue even fast one is > simply way too slow. > >> 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. > > > Well, that's precisely my use case. I don't even write a patch in a pure > Subversion checkout anymore these days. > > - R. Niwa > > -- > - 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 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
