<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Lei,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 20, 2015, at 11:21 AM, Lei Yang <<a href="mailto:yltt1234512@gmail.com" class="">yltt1234512@gmail.com</a>> wrote:</div></blockquote><div><br class=""></div>I am sorry it has taken me so long to test this workflow.</div><div><br class=""><blockquote type="cite" class="">Hi,<br class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="">Kunaal and I have completed a prototype of the first part of our GSoC project (implement a new doc toolchain). Our goal is to implement a doc toolchain for short how-to docs and lower the barrier for new comers to contribute.<br class=""></div></div></div></blockquote><div><br class=""></div><div>I am not trying to be dense, but I want to make sure I understand the goals here:</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is the workflow of the prototype:<br class="">1. Contributor creates a new pull request on GitHub<br class=""></div></div></div></blockquote><div><br class=""></div><div>A fairly well understand platform with lots of potential users - cool. Github also has some social cachet.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">2. A corresponding issue is automatically created on Pagure<br class="">3. Staff and contributor discuss on Pagure<br class=""></div></div></div></blockquote><div><br class=""></div><div>This part is a bit odd to me, today. I believe your goal is to make sure the discussion happens in a CentOS controlled space in case github ever becomes an issue. However, it seems odd that we don't just mirror the whole PR over (see below for where I read the paragraph where you said this was coming ...). Right now it is weird to have to visit one site to see the change and another to discuss it. Furthermore I feel like we are creating an educational challenge (which could be resolved with some great docs and a bot that posted in the PR on github) to get people to understand what is going on.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">4. When the pull request can be accepted, it is marked as “fixed”, and the pull request on github is automatically merged<br class=""></div></div></div></blockquote><div><br class=""></div>OK</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">5. New change is synced to Pagure (doc website will update according to Pagure repo, to be implemented later)<br class=""></div></div></div></blockquote><div><br class=""></div><div>While this makes sense, it seems like we are barely using github and I am not sure it is helping us in this equation completely. Can you help me understand what I am missing?</div><div><br class=""></div><div>Openstack does something sort of similar, but backwards from our workflow.</div><div><br class=""></div><div>They have both a private git (with gerrit) and a github repo. 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. 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.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We have made a prototype performing the steps above, and is now running ;) Next we plan to integrate a CI so the doc can be built in real time and ready for staff to review. Could you please give us some suggestions about the workflow above and about the toolchain? The original GSoC idea can be found here: <a href="http://wiki.centos.org/GSoC/2015/Ideas#docs-toolchain" class="">http://wiki.centos.org/GSoC/2015/Ideas#docs-toolchain</a> </div></div></div></blockquote><div><br class=""></div>I like the CI. I'd love to have us consider including something like emender in a future release that could do CI on the PR and post a response with any automated integration failures.</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We use Pagure as a part of the toolchain. Pagure is an excellent git-centered forge created by Pierre-Yves Chibon <<a href="mailto:pingou@pingoured.fr" class="">pingou@pingoured.fr</a>>. 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 doesn’t need to leave github in the whole process, which lowers the barrier of contributing a lot.</div></div></blockquote><div><br class=""></div><div>Do you have a timeline for the full PR mirroring?</div><div><br class=""></div><div>I agree that using github will definitely lower the barrier to contribution. My experience with sync problems has shown that two-way is problematic. Do you have a plan for that?</div><div><br class=""></div><div>Can we achieve our goals by having a one-way sync from github to pagure? This would seem to simplify the problem and provide us the protection - unless I am missing something.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">To test it, you may create a PR on github. A corresponding issue will be created automatically on Pagure, so you may go to Pagure.io to check it. If you want to merge the PR, change the status of issue from Open to Fixed on Pagure (need admin access to the repo, if you want to test this part, please email me or Kunaal <<a href="mailto:kunaalus@gmail.com" class="">kunaalus@gmail.com</a>> so we can add you as admin). Once the issue is marked as Fixed, the PR on github will be merged.</div></div></blockquote><div><br class=""></div>Feel free to merge or reject my PR as you see fit :)</div><div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Also, we are not very sure whether running a Pagure instance will add much workload to sys admin team. What’s your idea?</div></div></blockquote><div><br class=""></div>I can't speak to the overhead, but I can say that I believe having Pagure running is a good idea.</div><div><br class=""></div><div><div>regards,</div><div><br class=""></div><div>bex</div></div></div></body></html>