[CentOS-docs] Finished a prototype of GSoC project: Implement a new doc toolchain

Fri Jul 10 08:38:15 UTC 2015
Pierre-Yves Chibon <pingou at pingoured.fr>

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 at pobox.com>
>      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 at pingoured.fr>. 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
- 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

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 :)