[erlang-questions] On Pull Requests Comments

[Tuncer Ayaz]

On Mon, Oct 21, 2013 at 6:28 PM, Bjorn-Egil Dahlberg 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.

Should we skip sending mails to erlang-patches@ from now on?

> 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.

Given the use of pull requests for otp.git, what about automatically
syncing bugs to/from https://github.com/erlang/otp/issues?

>> 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

I think Anthony is right, and using the patch-queue approach of a
cleanly rebased branch, code comments can also disappear. I haven't
figured out the pattern yet, but sometimes after a rebase old comments
are still linked but collapsed, and sometimes they're gone. I prefer
Gerrit's code review functionality for this particularly feature.
Also, the way github inserts new commits into the discussion is
debatable.

> 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. =)