[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] WebKit Transition to Git
From: Tetsuharu OHZEKI <tetsuharu.ohzeki () gmail ! com>
Date: 2020-10-14 17:39:00
Message-ID: CAAY5diCvcdyU1q+NeSNB-SZH3RmnkpiSa6JV7UkZRGffyPe1RA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> 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@gmail.com
On Wed, Oct 14, 2020 at 11:12 PM Adrien Destugues
<pulkomandy@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
Tetsuharu OHZEKI
tetsuharu.ohzeki@gmail.com
[Attachment #5 (text/html)]
<div dir="auto">> The original goal mentionned at the start of the thread was \
encouraging<br> > more people to contribute to WebKit. From that side, what's \
important is<br> > trying to retain a patch submission workflow that's \
standardized. That can<br> > be github/gitlab style pull requests, or Gerrit which \
is a different one.<br> > There are probably others.<br>
><br>
> If the workflow for submitting patches requires writing a changelog file,<br>
> or other similar custom operations, I think that's more likely to turn<br>
> potential contributors away (I can only speak for myself, here, of course).<br>
> Even if you automate it with a script, people will have to remember to<br>
> use the script. Then it doesn't matter if you use Git or Github or some<br>
> other tool under the hood: the patch submission process is a custom one.<br>
><br>
> Starting from there, the question is more:<br>
><br>
> Which of these existing workflows is more suitable?<br>
><br>
> How much can we tweak them (with bots on Github, plugins<br>
> on Gerrit, or pre-commit/pre-push hooks on developer machines, for example)<br>
> to make them better fit the existing things that will probably be kept?<br>
> (I guess Apple internal bugtracker, possibly bugzilla as well, maybe some<br>
> parts of the existing build infrastructure and builder machines?).<br>
><br>
> Can these changes to the workflow be done and documented so that existing<br>
> Git (and Github/Gitlab/Gerrit/...) users can handle them easily?<br>
<br>
<br>
I agree that VCS is a one of the barriers to contribute to a new<br>
project at this era<br>
which is Git is a winner of VCS share.<br>
For that means, I think it's nice goal that WebKit moves Git<br>
even if we have been able to clone a repository by git-svn or<br>
<a href="https://github.com/WebKit/webkit" rel="noreferrer noreferrer" \
target="_blank">https://github.com/WebKit/webkit</a>.<br> <br>
By contrast, I doubt GitHub or GitLab would reduce a barrier for a new<br>
contributor.<br>
Every project has some customs and we need to know them on contributing.<br>
Especially, large projects have this tendency.<br>
<br>
As a contributor, there is no difference between learning WebKit scripts and<br>
pull requests conventions for each project hosted on GitHub.<br>
<br>
Personally, for welcome a contributor,<br>
it's important that a contributor can access a guide to such custom habit,<br>
receive a reviewer's quickly feedback, and easily find a good-first-bug,<br>
can access a design guide (This is best but I know it's hard), and etc.<br>
<br>
For these points, I feel today's WebKit goes positively.<br>
<br>
Of course, WebKit's testing has a strong habit and<br>
bunch of documents about that in <a href="http://trac.webkit.org" rel="noreferrer \
noreferrer" target="_blank">trac.webkit.org</a> are complex.<br> <br>
However, for example, Ryosuke-san's guide was pretty helpful for me.<br>
<a href="https://bugs.webkit.org/show_bug.cgi?id=217017" rel="noreferrer noreferrer" \
target="_blank">https://bugs.webkit.org/show_bug.cgi?id=217017</a>.<br> Some WebKit \
blog's articles related to JSC are nice because they<br> usually talk about \
design details (I'm a fan of them!).<br> I have not contributed to JSC but they \
help me with reading code.<br> <br>
Overall, as a newcomer contributor, I think WebKit goes positively.<br>
<br>
To be honest, I think that moving to GitHub cannot mean easily that to<br>
be welcome a new contributor.<br>
<br>
<br>
<br>
--<br>
Tetsuharu OHZEKI<br>
<a href="mailto:tetsuharu.ohzeki@gmail.com" target="_blank" \
rel="noreferrer">tetsuharu.ohzeki@gmail.com</a><br> <br>
<br>
<br>
<br>
<br>
On Wed, Oct 14, 2020 at 11:12 PM Adrien Destugues<br>
<<a href="mailto:pulkomandy@pulkomandy.tk" target="_blank" \
rel="noreferrer">pulkomandy@pulkomandy.tk</a>> wrote:<br> ><br>
> > 3. Changelog<br>
> > I don't feel it's a big problem to write ChangeLog file.<br>
> > Of course, this is tired thing but I don't have a strong alternative<br>
> > after reading this thread.<br>
> ><br>
> > However the current `prepare-Changelog` script does not fit with a<br>
> > branch -based workflow on Git, I feel. There is a room to polish on<br>
> > this Git migration.<br>
> ><br>
> > For example, I'd like to specify a branch as my working set in my<br>
> > local machine, instead of commit or staged changes.<br>
> ><br>
> > Ordinary, I do these flows but it's a bit tired…. (if you know more<br>
> > good ways, could you tell me!):<br>
> ><br>
> > 1. Run `prepare-Changelog`<br>
> > 2. Format ChangeLog file and remove duplicated entries added by _steps \
1_.<br> > > 3. Fuse new changes into a single patch by `git add . && \
git commit<br> > > --ammend` or `git commit --fixup HEAD && git rebase \
master -i<br> > > --autosquash`<br>
> > 4. Upload patches by `webkit-patch upload -g HEAD`<br>
> ><br>
> > I don't have an objection that we merge a squashed patch into trunk to<br>
> > simplify the history but we would have some chance to improve the \
script.<br> > ><br>
><br>
> The original goal mentionned at the start of the thread was encouraging<br>
> more people to contribute to WebKit. From that side, what's important is<br>
> trying to retain a patch submission workflow that's standardized. That \
can<br> > be github/gitlab style pull requests, or Gerrit which is a different \
one.<br> > There are probably others.<br>
><br>
> If the workflow for submitting patches requires writing a changelog file,<br>
> or other similar custom operations, I think that's more likely to turn<br>
> potential contributors away (I can only speak for myself, here, of course).<br>
> Even if you automate it with a script, people will have to remember to<br>
> use the script. Then it doesn't matter if you use Git or Github or some<br>
> other tool under the hood: the patch submission process is a custom one.<br>
><br>
> Starting from there, the question is more:<br>
><br>
> Which of these existing workflows is more suitable?<br>
><br>
> How much can we tweak them (with bots on Github, plugins<br>
> on Gerrit, or pre-commit/pre-push hooks on developer machines, for example)<br>
> to make them better fit the existing things that will probably be kept?<br>
> (I guess Apple internal bugtracker, possibly bugzilla as well, maybe some<br>
> parts of the existing build infrastructure and builder machines?).<br>
><br>
> Can these changes to the workflow be done and documented so that existing<br>
> Git (and Github/Gitlab/Gerrit/...) users can handle them easily?<br>
><br>
> --<br>
> Adrien.<br>
><br>
> _______________________________________________<br>
> webkit-dev mailing list<br>
> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank" \
rel="noreferrer">webkit-dev@lists.webkit.org</a><br> > <a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer \
noreferrer" target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br><div \
data-smartmail="gmail_signature">Tetsuharu OHZEKI<br><a \
href="mailto:tetsuharu.ohzeki@gmail.com">tetsuharu.ohzeki@gmail.com</a></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic