On Thu, Jul 09, 2015 at 02:11:26AM +0530, kunaal jain wrote: > On Thu, Jul 9, 2015 at 1:19 AM, Brian (bex) Exelbierd <bex@xxxxxxxxx> > They have both a private git (with gerrit) and a github repo.A If you > open a PR on github it is closed by a bot with instructions to submit > the PR via gerrit to their private repo.A When the PR is resolved and > merged in the private repo, the entire commit is pushed to github > awarding the social "status" that comes from a commit. I am not > suggesting we use gerrit. > > I agree. Main reason is because of two way sync of pagure and github. Once > that done, user even doesn't need to be aware that pagure exists. I agree > right now we are doing something like openstack which you described, but > we dont want that.A > [...] > > We use Pagure as a part of the toolchain. Pagure is an excellent > git-centered forge created byA Pierre-Yves Chibon > <pingou@xxxxxxxxxxxx>. Currently Pagure is in its early stage and the > APIs and web hooks are changing and improving. We are working closely > with Pierre to better integrate Pagure into the toolchain. In the > future we plan to sync complete pull request so that discussion can > happen either on github or Paugre, and contributor doesna**t need to > leave github in the whole process, which lowers the barrier of > contributing a lot. > > Do you have a timeline for the full PR mirroring? > I agree that using github will definitely lower the barrier to > contribution. My experience with sync problems has shown that two-way is > problematic.A Do you have a plan for that? > Can we achieve our goals by having a one-way sync from github to > pagure?A This would seem to simplify the problem and provide us the > protection - unless I am missing something. > > That is our priority. There was a couple of roadblocks, which I think are > now cleared. So we will be again working on full sync, and by this weekend > we hope we can achieve this. > Yes two way sync is very problematic. A mess of GitHub and pagure webhooks > and API, listening to each other. > Our aim is two way sync, if we fail, we can fall back to one way sync from > github to pagure. This will still achieve our goal, but then maybe not > every CentOS docs maintainer be open to idea of using Github. We had some > sort of these ideas in a discussion. So as far as I know, currently, you are using web-hooks to do sync between pagure and github. Did you consider using the underlying requests repo of the project? In other words, for each project in pagure, there are 4 git repos: - the code of the project (the repo people clone/fork/work on) - the doc repo, for storing the project's documentation if that project wishes to - the tickets repo of the project (a JSON representation of every issue ever opened against the project) - the request repo of the project (a JSON representation of every pull-request and discussion about it opened against the project) All links are available at the bottom of the project's overview page. Note: tickets and requests repos are private (only people with commit to the main repo can clone them) So when using the requests repo, upon receiving a notification from github, you could create/update the appropriate JSON blob representing the pull-request and push it to the requests repo. >From their pagure should update its database via a git hook to reflect the new/update the PR in its UI. Note: while interesting this is a part of the code that has been completely tested yet, so we might run into a few bugs (in this case I guess we would run into a few settings not being loaded correctly, nothing too problematic normally). Note2: I wonder if the PR model in Pagure could not be reworked so that it defines the address of the repo from which to pull the changes, rather than pointing to a pagure's project. This way, we could open a PR on pagure from a repo hosted elsewhere. So many ideas :) Pierre _______________________________________________ CentOS-docs mailing list CentOS-docs@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-docs
