Sent from my iPhone
> On Jun 14, 2017, at 8:44 AM, Bruce Schuchardt wrote:
>
> Having to deal with a github repo instead of branches off of the Apache repo
> is an additional burden on committers.
As a committee you have to work from the github repo to merge PRs from
non-committers. Having
I have to agree with Bruce here. This is an open community, and as such,
dictating whether or not we can use reviewboard for reviews works against the
openness. Furthermore, reviewboard is NOT restricted to committers - I
submitted many reviews using RB before becoming a committer. Once the revi
Having to deal with a github repo instead of branches off of the Apache
repo is an additional burden on committers.
I still vote -1 and don't see a lot of support for this idea.
On 6/13/17 3:03 PM, Jacob Barrett wrote:
On Mon, Jun 12, 2017 at 7:57 AM Bruce Schuchardt
wrote:
It places an un
On Mon, Jun 12, 2017 at 9:37 AM Dave Barnes wrote:
> 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
On Mon, Jun 12, 2017 at 7:57 AM Bruce Schuchardt
wrote:
> It places an unnecessary burden on committers
Considering committers need to use PR to commit changes from non-committers
how does reducing the number of review systems increase the burden on
committers?
> and git history is the
> defi
One feature I like about PRs on GitHub that I haven't figured out how to do
on Review Board is breaking up a large changeset (which I would like to
have reviewed together) into multiple commits. It can be a useful way to
tell a story about your changes, but keep the review for them in one place.
I
On Thu, Jun 8, 2017 at 2:24 PM Nabarun Nag wrote:
> Also, IMHO feature branches from which the PRs are created should be in our
> personal fork rather than the main geode git repo.
>
+1 - I had planned to bring this up in a separate discussion but yes, I
think all work should happen out of your
+1 on using PR.
We can use the @tags and the github notification page[Participating tag] to
check the PRs that need our attention.
Also, IMHO feature branches from which the PRs are created should be in our
personal fork rather than the main geode git repo. Because when we push a
branch called fea
On Thu, Jun 8, 2017 at 12:35 PM Mark Bretl wrote:
> I like the functionality we get with GitHub, including the Travis CI
> integration.
>
> Do we have a proposed workflow change for committers?
The proposed workflow change to committers is to use the same workflow as
contributors. The only diff
I like the functionality we get with GitHub, including the Travis CI
integration.
Do we have a proposed workflow change for committers?
--Mark
On Thu, Jun 8, 2017 at 11:20 AM, Jacob Barrett wrote:
> Some more fuel on this fire... PR's get checked against Travis CI
> automatically and the resul
Some more fuel on this fire... PR's get checked against Travis CI
automatically and the results show up in the PR. This is a good safety
check even for committers before merging their branch into the development
branch.
-Jake
On Thu, Jun 8, 2017 at 10:20 AM Dan Smith wrote:
> One thing that can
> help is if you add your github id to your apache profile - the PR will then
> show that it is coming from an apache member.
To illustrate what Dan is saying, notice the "Member" tag on my comment in
the screen cap below.
[i
+1 for just PRs
+1 for trying the functionality Jared has pointed out in Github
On Thu, Jun 8, 2017 at 10:19 AM, Jared Stewart wrote:
>
> On Jun 8, 2017, at 8:32 AM, Bruce Schuchardt
> wrote:
>
> I also don't see any way to push a PR to specific individuals for review.
> In Reviewboard there i
+1 to just using PRs.
I think the benefits to new people to the project make it worth it to
switch. New people will see PRs from committers when they are creating
their PRs, which will help provide good examples. It's one less system to
sign up on as a contributor so it's easier for new people to
On Thu, Jun 8, 2017 at 8:32 AM Bruce Schuchardt
wrote:
> One thing I find confusing in PRs is whether the person submitting the
> request is a committer or not. Non-committers need someone to merge the
> PR while committers are just looking for a review and will merge the
> changes to develop th
I've used both PRs and Review Boards for doc changes.
The Review Board's targeted reviewer list, as Bruce points out, is a plus.
It would be great if PRs could do that.
On Thu, Jun 8, 2017 at 9:28 AM, John Blum wrote:
> +1 to Bruce's comments.
>
> PRs are for contributors that do not have commit
On Thu, Jun 8, 2017 at 9:28 AM John Blum wrote:
> PRs are for contributors that do not have commit privileges. ReviewBoard
> is a tool for "reviewing" changes.
>
This isn't some law, it was our choice. What I am proposing is that we
re-evaluate this choice for consistency.
> However, what is
+1 to Bruce's comments.
PRs are for contributors that do not have commit privileges. ReviewBoard
is a tool for "reviewing" changes.
However, what is also common practice on open source projects, even for
committers, is to create a topic branch containing the commit with the
desired changes (labe
One thing I find confusing in PRs is whether the person submitting the
request is a committer or not. Non-committers need someone to merge the
PR while committers are just looking for a review and will merge the
changes to develop themselves.
I also don't see any way to push a PR to specific
All,
I would like to discuss transitioning all code reviews to pull requests
over using review board. For non-committer community members we ask them to
make pull requests against the mirrored GitHub repo. Some committers use
pull requests for their own work reviews while others use review board.
20 matches
Mail list logo
