> 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 <rn...@webkit.org> wrote:
>> 
>> 
>> On Tue, May 10, 2022 at 20:36 Chris Dumez <cdu...@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 <gga...@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

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to