Hi Ben, Joachim, Thank you for your checking and reply! After I'll be carefully considered, and then reply. I'll reflect your feedback. Please wait for a little while. Thank you very much :) , Takenobu 2016-10-28 22:01 GMT+09:00 Ben Gamari :

Takenobu Tani writes:

...

Hi devs,

For myself and new contributors, I drew overview pictures about GHC development flow.

GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow

Thanks Takenobu! This is quite helpful.

One minor inaccuracy I found was the spelling of "Arcanist" on page 12. Another is in the description of the ghc-proposals process on page 9. Specifically, I think the proposal process should look more like,

write the proposal ↓ pull request ↓ discussion ←┐ ←──┐ ↓ │ │ revise proposal ┘ │ ↓ │ request review │ by steering committee │ ↓ │ wait for approval ───┘ ↓ create ticket

Finally, I think it would be helpful if more attention could be given to the bug reporting protocol depicted on page 8. In particular, users have approached me in the past with questions about what the various ticket states mean. Really, it's (fairly) simple,

* New: The ticket is waiting for someone to look at it and/or discussion is underway on how to fix the issue

* Assigned: Someone has said they are working on fixing the issue.

* Patch: There is a patch to fix the issue that is awaiting review (it is typically listed in the "Differential Rev(s)" field of the ticket.

* Merge: A patch fixing the issue is present in the `master` branch and we are considering backporting it to the stable branch (e.g. currently the `ghc-8.0` branch).

* Closed: As of the release listed in the "Milestone" field the bug is considered resolved.

I think a diagram describing this workflow could be quite helpful. Let me know if I can help.

Cheers,

- Ben

Joachim Breitner writes:

Hi,

Am Freitag, den 28.10.2016, 21:19 +0900 schrieb Takenobu Tani:

...

For myself and new contributors, I drew overview pictures about GHC development flow.

  GHC development flow     http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf     https://github.com/takenobu-hs/ghc-development-flow

very nice! I wonder where we can keep it so that people will find it, and how to make sure it stays up-to-date.

You could add travis to the tools sections. It is, in a way, a second line of CI defense: Runs a bit less, but is available when Harbormaster fails, and is a different environment. Also, if you fork GHC on github, travis will automatically test your commits.

There is a box „committer flow“. What exactly is meant by that? Is there more to be said about that?

I think this means someone with commit bits simply pushing a patch without submitting to code review. Ideally we'd be able to deprecate this workflow in favor of the "auto-validating push" that you've proposed. I started looking at implementing this earlier this week; sadly Harbormaster doesn't make it easy as there is no way to manually fire off Harbormaster builds without creating a Diff. Nevertheless, I have an initial hack; perhaps I'll be able to finish it next week. Cheers, - Ben

Takenobu Tani writes:

Hi Ben, Joachim,

2016-10-29 1:36 GMT+09:00 Ben Gamari :

...

...

There is a box „committer flow“. What exactly is meant by that? Is there more to be said about that?

I think this means someone with commit bits simply pushing a patch without submitting to code review. Ideally we'd be able to deprecate this workflow in favor of the "auto-validating push" that you've proposed.

I assumed that "committer flow" is simply pushing a patch without submitting to code review or without discussion. I thought committers [1] have the authority in case of typo or small modification.

Do I misunderstand?

Nope, that's exactly right. Unfortunately, even "trivial" fixes have a tendency to break the tree (which has been happening too often recently) so I'm trying to push contributors to use CI whenever possible. Cheers, - Ben

Hi Ben, Joachim, 2016-10-30 2:07 GMT+09:00 Ben Gamari :

Nope, that's exactly right. Unfortunately, even "trivial" fixes have a tendency to break the tree (which has been happening too often recently) so I'm trying to push contributors to use CI whenever possible.

Thank you for explaining me. I understand the reason that you are talking about travis. 2016-10-30 2:59 GMT+09:00 Joachim Breitner :

I see. The term “flow” suggested something deeper or more structured (which might be good, but is not the case). Maybe relabel it “direct commit”.

Thank you. I'll update the "committer flow" to "direct commit" on page 7. It is more clear about the current situation. Regards, Takenobu

Hi Takenobu Thanks for writing this up. A small suggestion, for the box "Add a test case" it might be good to add a reference to https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding Also it might be good to add something about the process of fixing doc "bugs" and improving the doc. I think these are areas where less experienced Haskell developers can add value and contribute to the ghc community. Thanks again George On Sun, Oct 30, 2016 at 6:58 AM Takenobu Tani wrote:

Hi Ben, Joachim and devs,

I updated the following: * page 7: update "committer flow" to "direct commit" * page 9: add a simple diagram for the various ticket states * page 10: update ghc-proposals flow * page 13: correct "Arcanist" * page 13: add "travis"

Here is Rev.2016-Oct-30: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow

Please teach me if I have misunderstood, especially page 9.

Regards, Takenobu

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hi devs, 2016-10-31 20:02 GMT+09:00 Takenobu Tani :

...

Also it might be good to add something about the process of fixing doc "bugs" and improving the doc.

I think these are areas where less experienced Haskell developers can add value and contribute to the ghc community.

Indeed. It's good :) Update of documents is easy to contribute by new contributors. I'll understand the document process, then I'll try to draw the diagram.

I updated the following: * page 11: add a link for test case * page 12-15: add document flow Here is Rev.2016-Nov-03: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Please teach me if I have misunderstood, especially page 12-15. Thank you, Takenobu

Hi Ben, Thank you so much :) After I remove "DRAFT" watermark, I'll introduce this PDF to cafe. Regards, Takenobu 2016-11-03 21:20 GMT+09:00 Ben Gamari :

Takenobu Tani writes:

...

Hi devs,

2016-10-31 20:02 GMT+09:00 Takenobu Tani :

...

...

Also it might be good to add something about the process of fixing doc "bugs" and improving the doc.

I think these are areas where less experienced Haskell developers can add value and contribute to the ghc community.

Indeed. It's good :) Update of documents is easy to contribute by new contributors. I'll understand the document process, then I'll try to draw the diagram.

I updated the following: * page 11: add a link for test case * page 12-15: add document flow

Here is Rev.2016-Nov-03: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow

Please teach me if I have misunderstood, especially page 12-15.

Thanks, this looks great Takenobu!

Cheers,

- Ben