[webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Chris Dumez]

> On May 11, 2022, at 12:13 AM, Ryosuke Niwa via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
> On Tue, May 10, 2022 at 9:27 PM Ryosuke Niwa <rniwa at webkit.org> wrote:
>> 
>> 
>> On Tue, May 10, 2022 at 20:36 Chris Dumez <cdumez at 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 at lists.webkit.org> wrote:
>>> 
>>> On Tue, May 10, 2022 at 3:01 PM Jonathan Bedard via webkit-dev
>>> <webkit-dev at lists.webkit.org> wrote:
>>> 
>>> 
>>> 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.
>>> 
>>> 
>>> 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220511/7518d503/attachment.htm>