[webkit-dev] WebKit Transition to Git

[Konstantin Tokarev]

03.10.2020, 19:46, "Tetsuharu OHZEKI" <tetsuharu.ohzeki at gmail.com>:
>>>  I think having to create an account on a website isn't the main thing
>>>  preventing people to contribute anyway? It's more about having to use
>>>  project-specific tools to prepare the patch for submission (in the case
>>>  of WebKit, having to write the commit message in the Changelog file, for
>>>  example).
>>
>>  It's about all those things. We've definitely heard of people
>>  complaining or refusing to create a Bugzilla account to report bugs.
>>  I've gotta say I'm very much concerned about getting rid of change
>>  logs when we move to Git. We put a lot of useful information about
>>  what was causing the bug, how we fixed it, and why we fixed the way we
>>  did in a change log. I've seen a few projects which transitioned to
>>  Git and somehow lost the rigor in maintaining an equally high quality
>>  commit message, partly because most code review tools don't let you
>>  add inline comments to commit messages.
>
> I'd like to tell my feelings about a ChangeLog file other than
> perspective for code review.
>
> As a newbie patch contributor, it's true that ChangeLog file is a
> *bit* tired when I update a patch.
> I felt repeatedly that it should be replaced by VCS' commit log to
> make it easier.
>
> On the other hand, ChangeLog file also helps me many times when I dig
> into the history of WebKit
> because ChangeLog file contains what functions are removed in which
> commit with Bugzilla id
> and sometimes includes detailed reason for changeset.

FWIW, right now our ChangeLog entries are our commit messages too.
If we migrate to git is no additional value in keeping them separately,
because git log is local (no requests to server) and fast (you can search
in it with ~ same speed as in changelog files)

>
> Perhaps it may be just that I don't know the way, VCS (I think here is
> Git) has a powerful feature to trace when we added codes
> but it's hard to trace when we removed codes, and it force a tough
> work to me when I investigate why we introduced this line to fix a
> bug.

If you know piece of code or function name which was removed, you
can use git log -S to find commit where it was deleted.

> By contrast, WebKit's ChangeLog file is helpful to make it easier to
> trace both of adding ones and removing codes.
>
> --
> Tetsuharu OHZEKI
> tetsuharu.ohzeki at gmail.com
>
> On Sat, Oct 3, 2020 at 7:17 PM Ryosuke Niwa <rniwa at webkit.org> wrote:
>>  On Sat, Oct 3, 2020 at 2:25 AM Adrien Destugues
>>  <pulkomandy at pulkomandy.tk> wrote:
>>  >
>>  > On Fri, Oct 02, 2020 at 07:05:21PM -0500, Michael Catanzaro wrote:
>>  > > > I realize that Gerrit might not integrate at all with hosting the repo
>>  > > > on Github, but has any thought been given to this aspect of the
>>  > > > transition?
>>  > >
>>  > > That sounds like it would be a significant barrier to contribution, and
>>  > > frankly defeat the point of switching. If we have serious concerns with
>>  > > GitHub's code review functionality (which, again, I'm not familiar with),
>>  > > then we should just use GitLab and have everything in one place. (GitLab
>>  > > accepts GitHub logins via OAuth, both on gitlab.com and self-hosted
>>  > > instances, so the barrier to contributing remains low either way.)
>>  >
>>  > Gerrit accepts GitHub and other OAuth providers as well, so that's not a
>>  > problem. We have been using this for Haiku code reviews for a few years
>>  > now, and interestingly we got some complaints from people who don't want
>>  > to have a Github account (for various reasons) and won't use our code
>>  > review tool because of that.
>>  >
>>  > I think the integration referred to was rather in terms of having
>>  > reviews synchronized between Gerrit and Github pull requests, which is
>>  > also possible, but I think if the point is to use Github, it doesn't
>>  > work this way: if your workflow is too different from the standard way
>>  > to use Github, people will still be confused by it and it will still be
>>  > a barrier to contribution.
>>
>>  But using Gerrit would make that situation any better either.
>>
>>  > I think having to create an account on a website isn't the main thing
>>  > preventing people to contribute anyway? It's more about having to use
>>  > project-specific tools to prepare the patch for submission (in the case
>>  > of WebKit, having to write the commit message in the Changelog file, for
>>  > example).
>>
>>  It's about all those things. We've definitely heard of people
>>  complaining or refusing to create a Bugzilla account to report bugs.
>>  I've gotta say I'm very much concerned about getting rid of change
>>  logs when we move to Git. We put a lot of useful information about
>>  what was causing the bug, how we fixed it, and why we fixed the way we
>>  did in a change log. I've seen a few projects which transitioned to
>>  Git and somehow lost the rigor in maintaining an equally high quality
>>  commit message, partly because most code review tools don't let you
>>  add inline comments to commit messages.
>>
>>  - R. Niwa
>>  _______________________________________________
>>  webkit-dev mailing list
>>  webkit-dev at lists.webkit.org
>>  https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


-- 
Regards,
Konstantin