Hi, On Tue, 06 Oct 2020 03:42:11 +0300 Konstantin Tokarev <[email protected]> wrote: > 05.10.2020, 13:26, "Frédéric Wang" <[email protected]>: > > 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 [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
