[webkit-dev] WebKit Transition to Git

[Maciej Stachowiak]

> On Oct 3, 2020, at 9:42 AM, Tetsuharu OHZEKI <tetsuharu.ohzeki at gmail.com> wrote:
> 
>>> 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.

I think we should come up with a way to have the same level of detail in commit messages as is currently present in ChangeLog entries.

One example: ChangeLog-style commit message is included in a file in the diff (so that the review tool can properly review it), and it would be dropped and converted to a commit entry at merge time.

> 
> 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.
> 
> 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.
> 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 <mailto:tetsuharu.ohzeki at gmail.com>
> 
> On Sat, Oct 3, 2020 at 7:17 PM Ryosuke Niwa <rniwa at webkit.org <mailto:rniwa at webkit.org>> wrote:
>> 
>> On Sat, Oct 3, 2020 at 2:25 AM Adrien Destugues
>> <pulkomandy at pulkomandy.tk <mailto: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 <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201013/bc90cdbe/attachment.htm>