[erlang-questions] On Pull Requests Comments

[Björn-Egil Dahlberg]

On 2013-10-22 12:01, Anthony Ramine wrote:
>> 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 don't force anything. We create PR's to keep it consistent.
>> >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.
Forgotten, unhandled or in a big bag of mail-threads, i.e. lost.
>> >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.
We could in an ideal world. Actually that's what I want and with a sync 
to github. We don't have the time to do that now though.
>> >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.
Yes, i've heard this before. "Le'ts reduce it to the crudest form so we 
can rebuild it later."

>> >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 do not think Mailing Lists is the solution though. It is not 
structured enough.
>> >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.
Nice one.

Seriously Anthony, that is low. The community expresses a whish, go 
github. We follow and add github pr's and it actually turns out it makes 
things easier for us. You then say it is a mute point? That is low.

I agree with you that archiving can be a problem. I actually get all 
PR's as mails. I think others can to by watching the PR's. That might 
solve your problem.

I like others to weigh in too.

Are PR's as bad as Anthony points out? Should we kill it and use mails only?

// Björn-Egil