[webkit-dev] WebKit Transition to Git

[Tetsuharu OHZEKI]

> The original goal mentionned at the start of the thread was encouraging
> more people to contribute to WebKit. From that side, what's important is
> trying to retain a patch submission workflow that's standardized. That can
> be github/gitlab style pull requests, or Gerrit which is a different one.
> There are probably others.
>
> If the workflow for submitting patches requires writing a changelog file,
> or other similar custom operations, I think that's more likely to turn
> potential contributors away (I can only speak for myself, here, of
course).
> Even if you automate it with a script, people will have to remember to
> use the script. Then it doesn't matter if you use Git or Github or some
> other tool under the hood: the patch submission process is a custom one.
>
> Starting from there, the question is more:
>
> Which of these existing workflows is more suitable?
>
> How much can we tweak them (with bots on Github, plugins
> on Gerrit, or pre-commit/pre-push hooks on developer machines, for
example)
> to make them better fit the existing things that will probably be kept?
> (I guess Apple internal bugtracker, possibly bugzilla as well, maybe some
> parts of the existing build infrastructure and builder machines?).
>
> Can these changes to the workflow be done and documented so that existing
> Git (and Github/Gitlab/Gerrit/...) users can handle them easily?


I agree that VCS is a one of the barriers to contribute to a new
project at this era
which is Git is a winner of VCS share.
For that means, I think it's nice goal that WebKit moves Git
even if we have been able to clone a repository by git-svn or
https://github.com/WebKit/webkit.

By contrast, I doubt GitHub or GitLab would reduce a barrier for a new
contributor.
Every project has some customs and we need to know them on contributing.
Especially, large projects have this tendency.

As a contributor, there is no difference between learning WebKit scripts and
pull requests conventions for each project hosted on GitHub.

Personally, for welcome a contributor,
it's important that a contributor can access a guide to such custom habit,
receive a reviewer's quickly feedback, and easily find a good-first-bug,
can access a design guide (This is best but I know it's hard), and etc.

For these points, I feel today's WebKit goes positively.

Of course, WebKit's testing has a strong habit and
bunch of documents about that in trac.webkit.org are complex.

However, for example, Ryosuke-san's guide was pretty helpful for me.
https://bugs.webkit.org/show_bug.cgi?id=217017.
Some WebKit blog's articles related to JSC are nice because they
usually talk about design details (I'm a fan of them!).
I have not contributed to JSC but they help me with reading code.

Overall, as a newcomer contributor, I think WebKit goes positively.

To be honest, I think that moving to GitHub cannot mean easily that to
be welcome a new contributor.



--
Tetsuharu OHZEKI
tetsuharu.ohzeki at gmail.com





On Wed, Oct 14, 2020 at 11:12 PM Adrien Destugues
<pulkomandy at pulkomandy.tk> wrote:
>
> > 3. Changelog
> > I don’t feel it's a big problem to write ChangeLog file.
> > Of course, this is tired thing but I don’t have a strong alternative
> > after reading this thread.
> >
> > However the current `prepare-Changelog` script does not fit with a
> > branch -based workflow on Git, I feel. There is a room to polish on
> > this Git migration.
> >
> > For example, I’d like to specify a branch as my working set in my
> > local machine, instead of commit or staged changes.
> >
> > Ordinary, I do these flows but it’s a bit tired…. (if you know more
> > good ways, could you tell me!):
> >
> > 1. Run `prepare-Changelog`
> > 2. Format ChangeLog file and remove duplicated entries added by _steps
1_.
> > 3. Fuse new changes into a single patch by `git add . && git commit
> > --ammend` or `git commit --fixup HEAD && git rebase master -i
> > --autosquash`
> > 4. Upload patches by `webkit-patch upload -g HEAD`
> >
> > I don’t have an objection that we merge a squashed patch into trunk to
> > simplify the history but we would have some chance to improve the
script.
> >
>
> The original goal mentionned at the start of the thread was encouraging
> more people to contribute to WebKit. From that side, what's important is
> trying to retain a patch submission workflow that's standardized. That can
> be github/gitlab style pull requests, or Gerrit which is a different one.
> There are probably others.
>
> If the workflow for submitting patches requires writing a changelog file,
> or other similar custom operations, I think that's more likely to turn
> potential contributors away (I can only speak for myself, here, of
course).
> Even if you automate it with a script, people will have to remember to
> use the script. Then it doesn't matter if you use Git or Github or some
> other tool under the hood: the patch submission process is a custom one.
>
> Starting from there, the question is more:
>
> Which of these existing workflows is more suitable?
>
> How much can we tweak them (with bots on Github, plugins
> on Gerrit, or pre-commit/pre-push hooks on developer machines, for
example)
> to make them better fit the existing things that will probably be kept?
> (I guess Apple internal bugtracker, possibly bugzilla as well, maybe some
> parts of the existing build infrastructure and builder machines?).
>
> Can these changes to the workflow be done and documented so that existing
> Git (and Github/Gitlab/Gerrit/...) users can handle them easily?
>
> --
> Adrien.
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
Tetsuharu OHZEKI
tetsuharu.ohzeki at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20201015/30edf5b1/attachment.htm>