Hi, On Tue, 06 Oct 2020 03:42:11 +0300 Konstantin Tokarev <annu...@yandex.ru> wrote: > 05.10.2020, 13:26, "Frédéric Wang" <fw...@igalia.com>: > > One thing to take into account is that WebKit's repository is big and > > public GitHub/GitLab prevent creating large repository by default. This > > means it might not be possible for contributors to actually fork > > WebKit's repository on their account and then create a pull request > > (which is the standard way IIUC). > > Every repository which is already present on GitHub can be forked by > anyone without any restrictions. > > There are restrictions for repositories which are not forks, e.g. if you > create new repo on your account and try to push whole WebKit there, > you'll get an error. > > > Instead, we would probably end up > > doing like web-platform-tests and give contributors the permission to > > create branches to the WebKit account and make Pull Request to the > > master branch. > > This is not needed and should be avoided - private development branches > in main repo will confuse users and will be copied into all forks. While I agree that having private development branches in the main repository can be confusing for people not used to that, OTOH it is awkward to have to “fork” [1] the repository to one's user area, then add an extra remote to one's local clone of the upstream (main) repository, just to be able to submit a “pull request” [2].
Also with Git{Hub,Lab} it's an annoyance that one has to go through the web interface to create a “pull request”. Being able to do “webkit-patch upload” saves a non negligible amount of developer time. It is even better with Gerrit: do “git push” directly to a remote ref and a changeset will be automatically created for review [3]. > >Probably, we should forbid people to commit to the master > > branch directly (I think someone broke WPT's master branch that way last > > year)... > > I have to admit that ability to make small unreviewed commit for thing like > typo fix or change in personal watchlist is rather useful... I suppose this could be solved by still making a “pull request” and tagging it with some label to be merged automatically by some bot. It won't be as fast as directly landing a patch, but on the upside all patches (including unreviewed ones) would be landed in the same way. As a side note, Gerrit can be configured to allow direct pushes that bypass the review process. Cheers, —Adrián --- [1] I put “fork” in between quotes because it's a perversion of the term: what it does is create a clone of the repository in Git{Hub,Lab}'s own servers which happens to be accessible remotely with one's credentials. [2] GitHub's usage of the “pull request” term is yet another perversion: Git has had a pull requests (produced by a command) long before GitHub even existed, see https://git-scm.com/docs/git-request-pull [3] https://gerrit-documentation.storage.googleapis.com/Documentation/3.2.3/intro-user.html#upload-change
pgpEp7XcmnUrw.pgp
Description: PGP signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev