<div dir="ltr"><div>Hi Ben, Joachim,</div><div><br></div><div>Thank you for your checking and reply!</div><div>After I'll be carefully considered, and then reply.</div><div>I'll reflect your feedback.</div><div><br></div><div>Please wait for a little while.</div><div><br></div><div>Thank you very much :) ,</div><div>Takenobu</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-10-28 22:01 GMT+09:00 Ben Gamari <span dir="ltr"><<a href="mailto:ben@smart-cactus.org" target="_blank">ben@smart-cactus.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Takenobu Tani <<a href="mailto:takenobu.hs@gmail.com">takenobu.hs@gmail.com</a>> writes:<br>
<br>
> Hi devs,<br>
><br>
> For myself and new contributors, I drew overview pictures about GHC<br>
> development flow.<br>
><br>
> GHC development flow<br>
> <a href="http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf" rel="noreferrer" target="_blank">http://takenobu-hs.github.io/<wbr>downloads/ghc_development_<wbr>flow.pdf</a><br>
> <a href="https://github.com/takenobu-hs/ghc-development-flow" rel="noreferrer" target="_blank">https://github.com/takenobu-<wbr>hs/ghc-development-flow</a><br>
><br>
</span>Thanks Takenobu! This is quite helpful.<br>
<br>
One minor inaccuracy I found was the spelling of "Arcanist" on page<br>
12. Another is in the description of the ghc-proposals process on<br>
page 9. Specifically, I think the proposal process should look more<br>
like,<br>
<br>
write the proposal<br>
↓<br>
pull request<br>
↓<br>
discussion ←┐ ←──┐<br>
↓ │ │<br>
revise proposal ┘ │<br>
↓ │<br>
request review │<br>
by steering committee │<br>
↓ │<br>
wait for approval ───┘<br>
↓<br>
create ticket<br>
<br>
Finally, I think it would be helpful if more attention could be given to<br>
the bug reporting protocol depicted on page 8. In particular, users have<br>
approached me in the past with questions about what the various ticket<br>
states mean. Really, it's (fairly) simple,<br>
<br>
* New: The ticket is waiting for someone to look at it and/or<br>
discussion is underway on how to fix the issue<br>
<br>
* Assigned: Someone has said they are working on fixing the issue.<br>
<br>
* Patch: There is a patch to fix the issue that is awaiting review (it<br>
is typically listed in the "Differential Rev(s)" field of the ticket.<br>
<br>
* Merge: A patch fixing the issue is present in the `master` branch and<br>
we are considering backporting it to the stable branch (e.g.<br>
currently the `ghc-8.0` branch).<br>
<br>
* Closed: As of the release listed in the "Milestone" field the bug is<br>
considered resolved.<br>
<br>
I think a diagram describing this workflow could be quite helpful. Let<br>
me know if I can help.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
</blockquote></div><br></div>