My personal opinion on this is that adding a bot:rebase command is a bit silly.
IMO only the author of the PR should be allowed to issue this command, since
it modifies his/her fork repo, in which case why not just use the git command
line to do this? We shouldn't be implementing a full copy o
Ralph and I chatted more about this on the phone.
Short version: we think we generally agree. :-)
A point that was missed in the prior email discussion was that when we click
the green "merge" button, it puts effectively those commits at the HEAD --
which, for the purposes of this conversation
rebase before merge is a good practice/gate used by other code review tools
(like gerrit).
it helps to keep git history linear (less merge commits) and takes the most
recent patch set from PR and have it rebased onto the tip of the
destination branch. If rebase succeeds (no conflicts) - jenkins wi
Thinking about this a little bit, there's a wrinkle: you (the individual
developer) will need to give push permissions on your ompi / ompi-release fork
to the OMPIBot Github account. Otherwise, it won't be able to push back to
your fork.
Thinking about this even more, I'm a little worried abou
Mike:
This sounds good, but let us get the label/milestone/assign thing going first.
I'm thinking that the functionality you describe may become a different bot...?
I'm not sure.
> On Feb 5, 2015, at 9:56 AM, Mike Dubman wrote:
>
> yep, exactly.
>
>
> On Thu, Feb 5, 2015 at 2:35 PM, Jeff
We can definitely make this a per-branch (i.e., per-RM) decision. It's just a
little PHP code -- no problem.
Given timezone differences, give Gilles and me another day or three to get this
all sorted out.
So it'll be:
- pushing commits will remove "reviewed" and "rm-approval" labels, and will
I agree that others should be responsible for the review. However, just saying
“well they did a sloppy job” doesn’t resolve the problem. It has happened on
more than one occasion, so it is something that tends to slip by.
If the community doesn’t want to remove the approval, then I can live with
The RM should not be expected to read and accept the code itself, but his
role should be limited to accepting the idea behind the patch and making
sure it is compatible with the rules in place. As such, removing the
RM-approval mark is not yielding any benefits.
Moreover, based on the ideas propos
> On Feb 5, 2015, at 7:17 AM, Howard Pritchard wrote:
>
> Hi Jeff
>
> Gilles ideas are great.
>
> I agree with your RM stamp of approval policy. No removal of rm approved in
> the event of subsequent commits.
>
>
I disagree, so perhaps that should be something settable by the RM for a giv
Hi Jeff
Gilles ideas are great.
I agree with your RM stamp of approval policy. No removal of rm approved in
the event of subsequent commits.
Howard
On Feb 5, 2015 5:04 AM, "Jeff Squyres (jsquyres)"
wrote:
> Gilles came up with a cool idea for the OMPIBot (see below). We can do
> this idea, bu
yep, exactly.
On Thu, Feb 5, 2015 at 2:35 PM, Jeff Squyres (jsquyres)
wrote:
> On Feb 5, 2015, at 7:20 AM, Mike Dubman wrote:
> >
> > sounds cool and useful.
>
> K, thanks.
>
> > Also, does it make sense to have "rebase" knob to cause "try rebase if
> no conflicts" with upstream?
>
> Just to b
I like the concept and the proposed functionality. I also agree it should be a
common format or else it will be too confusing.
My “RM-opinion” is that someone pushing new commits to a PR should cause the
RM-approved label to be removed. I’m sure people wouldn’t abuse it, but we
shouldn’t create
A further thought:
If we're going to make a *bunch* of bot commands for issues / PRs / comments,
perhaps there should be a common form:
bot:label:LABEL
bot:nolabel:LABEL
bot:milestone:MILESTONE
bot:nomilestone
bot:assign:USER
bot:unassign
bot:jenkins:retest
bot:jenkins:retest-thread
...?
> O
On Feb 5, 2015, at 7:20 AM, Mike Dubman wrote:
>
> sounds cool and useful.
K, thanks.
> Also, does it make sense to have "rebase" knob to cause "try rebase if no
> conflicts" with upstream?
Just to be sure what you mean: something like "rebase:" that will cause the
patch set to be rebased to
sounds cool and useful.
Also, does it make sense to have "rebase" knob to cause "try rebase if no
conflicts" with upstream?
On Thu, Feb 5, 2015 at 2:04 PM, Jeff Squyres (jsquyres)
wrote:
> Gilles came up with a cool idea for the OMPIBot (see below). We can do
> this idea, but I want to make su
Gilles came up with a cool idea for the OMPIBot (see below). We can do this
idea, but I want to make sure that everyone is ok with it first.
Consider this scenario:
1. You create a PR
2. Over time, it gets reviewed, and then RM approved (i.e., the "reviewed" and
"rm-approved" labels are added)
+1
great stuff
2015-02-04 5:55 GMT-07:00 Jeff Squyres (jsquyres) :
> OMPI devs --
>
> Per lots of previous discussions, you all know that you can't assign
> labels, milestones, or users to issues/pull requests on the ompi-release
> repo.
>
> Gilles has written a Github bot that will allow you to
OMPI devs --
Per lots of previous discussions, you all know that you can't assign labels,
milestones, or users to issues/pull requests on the ompi-release repo.
Gilles has written a Github bot that will allow you to do these things by
inserting special tokens in the text of issues/pull requests
18 matches
Mail list logo
