Hi, I was wondering what was the common/best practice when you want to contribute (with commits) to an existing PR (assuming you have no commit rights on the branch where the PR comes from) : - Commits on the PR is only the responsability of the one who created it, he has to report the fixes. - The "fixer" forks the PR branch, fix it, close the old PR and resubmit a new PR - The "fixer" forks the PR branch, fix it and submit a PR to the branch from the original PR (this way after the merge, the existing PR will be updated) - For big PRs where other team members are likely to submits commits make sure to submit a PR from the aerogear repo ? (but this just counts for team members) Thx for you input ! Seb _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

I tend to use #3 or #4 On Tue, Sep 17, 2013 at 11:19 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: I've praticed #3 when working with iOS fellows. At least it keeps an ownership of the PR. But it might be a case by case choice depending on what is more efficient. ++ Corinne On Sep 17, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > Hi, > I was wondering what was the common/best practice when you want to contribute (with commits) to an existing PR (assuming you have no commit rights on the branch where the PR comes from) : > > - Commits on the PR is only the responsability of the one who created it, he has to report the fixes. > > - The "fixer" forks the PR branch, fix it, close the old PR and resubmit a new PR > > - The "fixer" forks the PR branch, fix it and submit a PR to the branch from the original PR (this way after the merge, the existing PR will be updated) > > - For big PRs where other team members are likely to submits commits make sure to submit a PR from the aerogear repo ? (but this just counts for team members) > > Thx for you input ! > > Seb > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 for #3 On Tue, Sep 17, 2013 at 8:46 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > Agree. #3 and #4 though #4 is a much less likely scenario. > > On Sep 17, 2013, at 4:31 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > I tend to use #3 or #4 > > > On Tue, Sep 17, 2013 at 11:19 AM, Corinne Krych > <corinnekrych(a)gmail.com&gt;wrote: > >> I've praticed #3 when working with iOS fellows. At least it keeps an >> ownership of the PR. But it might be a case by case choice depending on >> what is more efficient. >> >> ++ >> Corinne >> On Sep 17, 2013, at 11:14 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >> wrote: >> >> > Hi, >> > I was wondering what was the common/best practice when you want to >> contribute (with commits) to an existing PR (assuming you have no commit >> rights on the branch where the PR comes from) : >> > >> > - Commits on the PR is only the responsability of the one who created >> it, he has to report the fixes. >> > >> > - The "fixer" forks the PR branch, fix it, close the old PR and >> resubmit a new PR >> > >> > - The "fixer" forks the PR branch, fix it and submit a PR to the branch >> from the original PR (this way after the merge, the existing PR will be >> updated) >> > >> > - For big PRs where other team members are likely to submits commits >> make sure to submit a PR from the aerogear repo ? (but this just counts for >> team members) >> > >> > Thx for you input ! >> > >> > Seb >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >