> Github's code review UI has a couple of feature gaps in my opinion. It's > difficult to look at earlier versions of the pull request, in particular to > verify that issues found during code review have been fixed. I remember it > also being difficult to figure out whether all comments on earlier versions > have been addressed. > > Gerrit code review has worked well in my experience. It explicitly manages > different versions of the same patch set, and prominently shows whether all > code review comments have been addressed. > > 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?
I agree, not only because I think Gerrit is a better tool for code review, but also because with Git, the tool you chose has a large impact on the way you work. Git provides a framework, and both Github and Gerrit use this tool to implement quite different workflows and way to manage code review and patches. I think that is possibly more important than picking an hosting place based only on its popularity, because if the tool doesn't match the way you want to work, you will workaround it and the situation will not be a lot better than it is now: you will end up with custom scripts to help sending patches the correct way, and for contributors it won't be anything like contributing to another github hosted repo anyway. That being said, in my case I can say that if the patch submission process is simplified by using standard git tools, I'm indeed more likely to consider trying to upstream the Haiku port or at least some parts of our changes. In the current situation it indeed seems easier to maintain our fork on our side instead. -- Adrien / PulkoMandy _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
