[erlang-questions] On Pull Requests Comments

[Anthony Ramine]

Replied inline.

-- 
Anthony Ramine

Le 21 oct. 2013 à 18:28, Björn-Egil Dahlberg <egil@REDACTED> a écrit :

> Just to say why we create pull requests for most (all?) patches nowadays.

I understand that, but why force people who prefer the mailing-list to comment on GitHub?

> We create them because the changes are then easily put into our review system and we can actually keep track of them. With the ML's the patches can get lost in the signal/noise ratio.

I don't see how patches can get lost on erlang-patches, it's not like bugs, questions and patches end up in the same place.

> We at OTP don't use GitHub for bug-tracking, we merely use GH as a conduit to you, the community, and it seemed like the most effective tool for us to do this. We can also automate certain things for it, like doc and build testing. Saves time.

Couldn't you improve your internal bug-tracking to expose some parts of it to the public? That would certainly make things more future proof.

> I don't share your concern that the history of a pull requsts can change or gets lost (deleted). I mean, I do belive this might happen but the information in a PR should translate to an OTP-ticket and all the relevant information should be either in the commit message or the ticket (or both). I view PR and ML information as transient data to forward the work of the patch. The relevant information should be in the commit message when final.

I can download the whole erlang-patches archives, I have already found interesting stuff in it. When we switch off GitHub in a few years, this won't be doable for everything that will have happened meanwhile.

> But I've certianly been the there. Pondering "what were they thinking" when reviewing legacy code. In Git, this information should be in the commit message .. not in a mail discussion (or in a PR). So if anything, we should be even harder on clear and informative commit messages.

That's an ideal, but reality says otherwise. Especially so for rejected patches where there is no commit, by definition (e.g. the previous attempts to fix the =<< situation).

> I think we should give GitHub a little more time. I think pull requests is a nice addition as it saves time for us. ML's are just awful in this regard. I don't think we have found the optimal ways of working with GitHub, ML's and patches yet. We are still learning.

The initial point of supporting GitHub's PRs was to make the work easier for the community, not the OTP team.