> 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.ohz...@gmail.com On Wed, Oct 14, 2020 at 11:12 PM Adrien Destugues <pulkoma...@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.ohz...@gmail.com
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev