+1 for PRs in Github - one place, simple
On Wed, Jun 14, 2017 at 9:17 AM, Kenneth Howe wrote:
> -1 per my comments on the [DISCUSS] thread
>
> > On Jun 11, 2017, at 9:51 AM, Jacob Barrett wrote:
> >
> > After a few days of discussion [1] this thread has quieted down so I
> would
> > like to tak
-1 per my comments on the [DISCUSS] thread
> On Jun 11, 2017, at 9:51 AM, Jacob Barrett wrote:
>
> After a few days of discussion [1] this thread has quieted down so I would
> like to take it to a vote. The proposal is to modify the workflow of
> committers to match that of non-committers such t
On Mon, Jun 12, 2017 at 4:20 PM Udo Kohlmeyer
wrote:\
> * -1 for PR: I fear that given the huge amount of incoming PR's we
> might loose sight/oversight of any PR's that need to be approved
> from external submitters.
How does having to check review board and PR help this situation?
We can always set up a bit of automation so that committers are notified if
a PR sits unattended for a period of time.
--Jens
On Mon, Jun 12, 2017 at 4:20 PM, Udo Kohlmeyer
wrote:
> 0 for PR - I feel that both have their benefits and downsides.
>
> * +1 for PR: As Naba stated, the integration
0 for PR - I feel that both have their benefits and downsides.
* +1 for PR: As Naba stated, the integration is simplified and using
Intellij there is even support to create a PR. Single system to rule
them all.
* -1 for PR: I fear that given the huge amount of incoming PR's we
might lo
+1 On using PR. I feel using github PR is more convenient because of the
following reasons
a. Commit messages are automatically made into the header and description
in PR, whereas in reviewboard, you upload the patch and do all the writing
- manually. It feels redundant.
b. After changing the cod
+0
Proposal as written says "...for changes that would require peer review
before committing...".
If this means that minor changes (in my case, typo repairs are the common
case) can be checked in without going through a PR process, I can go with
the group decision.
Still see no compelling need to r
-1
It places an unnecessary burden on committers and git history is the
definitive record of changes to the code so github pr history isn't
really very useful. Also, Review Board is a much better tool for
reviewing code than a github PR.
On 6/11/17 9:51 AM, Jacob Barrett wrote:
After a fe
After a few days of discussion [1] this thread has quieted down so I would
like to take it to a vote. The proposal is to modify the workflow of
committers to match that of non-committers such that committers shall:
* Perform all work in progress on branches in their personal forks on
GitHub rather
