[erlang-questions] On Pull Requests Comments

ANTHONY MOLINARO anthonym@REDACTED
Mon Oct 21 18:42:06 CEST 2013


Hi,

I am certain the folks at github would love feedback on their system.  It seems like Fred's idea of uneditable comments would be something they might consider as a repository specific control.  I'd recommend sending them an email with suggestions.

-Anthony

On Oct 21, 2013, at 9:28 AM, Björn-Egil Dahlberg <egil@REDACTED> wrote:

> On 2013-10-21 13:31, Anthony Ramine wrote:
>> I was not against pull requests in the beginning because I had gathered that whether patches were discussed on GitHub or the mailing-list was at the submitter convenience. But then every time I submitted a patch, a pull request was created for it.
> Just to say why we create pull requests for most (all?) patches nowadays.
> 
> 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.
> 
> 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.
> 
>> I don't care about pull requests for typos, but that's all they should be used for.
> My thoughts on this.
> 
> I will certianly agree with you that GH has shortcomings. Especially with issue tracking but also with pull requests (to a lesser degree). I don't think we will ever use the issue tracking on GH as it is just plain awful for larger projects but it might be suitable for other things, like community driven tasks.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> As always, your feedback is welcomed! We strive to make this better for all involved. =)
> 
> // Björn-Egil
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions




More information about the erlang-questions mailing list