[CentOS-docs] Finished a prototype of GSoC project: Implement a new doc toolchain
Pierre-Yves Chibon
pingou at pingoured.fr
Fri Jul 10 08:38:15 UTC 2015
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
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
More information about the CentOS-docs
mailing list