Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs
On Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa <rniwa@webkit.org> wrote:
On Tue, May 10, 2022 at 20:36 Chris Dumez <cdumez@apple.com> 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 <webkit-dev@lists.webkit.org> wrote:
On May 10, 2022, at 2:46 PM, Geoffrey Garen <ggaren@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.
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
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 <rniwa@webkit.org> wrote:
On Tue, May 10, 2022 at 20:36 Chris Dumez <cdumez@apple.com> 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 <webkit-dev@lists.webkit.org> wrote:
On May 10, 2022, at 2:46 PM, Geoffrey Garen <ggaren@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.
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
On Wed, May 11, 2022 at 08:12 Chris Dumez <cdumez@apple.com> 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 <rniwa@webkit.org> wrote:
On Tue, May 10, 2022 at 20:36 Chris Dumez <cdumez@apple.com> 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 <webkit-dev@lists.webkit.org> wrote:
On May 10, 2022, at 2:46 PM, Geoffrey Garen <ggaren@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.
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
participants (2)
-
Chris Dumez
-
Ryosuke Niwa