[webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Ryosuke Niwa]

On Wed, May 11, 2022 at 08:12 Chris Dumez <cdumez at apple.com> wrote:

>
> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220511/c937a098/attachment.htm>