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

杨垒 yltt1234512 at gmail.com
Fri Jul 10 16:58:28 UTC 2015


Hi Pierre,

Thank you very much!


> 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?

Yes, I also think it is the best way to track PRs. GitHub PRs are equivalents of Pagure requests. And we can include more metadata in requests. 

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

Really helpful, thanks! It is more flexible than using API / web hooks.

If we run a pagure instance locally, we just directly modify the ticket repo, commit the changes and all set ;) Love it!

> 
> 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.

We keep the code repo synced using a same workflow (pull from github to get the changes, then push to pagure) now. I think it will also work well for ticket 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.

If we have this feature, that'll be awesome! The major problem of using requests now is about creating requests. Because we have to create a pagure project for each user who open a PR on github (so pagure can pull the changes from those projects). Also, we need to create an account for each user. That’ll be difficult to manage. If we can pull changes directly from github, then all we need is a link :)

We are now implementing a two-way sync between pagure and github (mainly comments, so users and staff can discuss and don’t need to leave their own platform). Two-way syncs are a little bit tricky, though ;) I think we may encounter some problems when dealing with high frequency changes.

> 
> So many ideas :)
> 
> 
> Pierre
> _______________________________________________
> CentOS-docs mailing list
> CentOS-docs at centos.org <mailto:CentOS-docs at centos.org>
> http://lists.centos.org/mailman/listinfo/centos-docs <http://lists.centos.org/mailman/listinfo/centos-docs>

Best regards,
Lei
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-docs/attachments/20150711/0467eff8/attachment.html>


More information about the CentOS-docs mailing list