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
We can "release it" at any time (i.e., apply it to the ompi-release repo) -- I
just wanted to get some feedback before doing so. Especially from Ralph, since
he's the current RM.
But per my other email and the timezones involved, give Gilles and me another
day or three to get this coded up and
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
HI Jeff and Gilles
Do we have an ETA for enabling the bot on ompi-release?
I think it will be a great help.
Howard
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
Thank you!
I think Nathan may actually be back at work; hopefully he can look at this
shortly.
> On Feb 5, 2015, at 7:36 AM, Alina Sklarevich
> wrote:
>
> Hi,
>
> Sure:
> https://github.com/open-mpi/ompi-release/issues/178
>
> Thanks,
> Alina.
>
> On Sat, Jan 31, 2015 at 3:39 PM, Jeff Sq
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
Hi,
Sure:
https://github.com/open-mpi/ompi-release/issues/178
Thanks,
Alina.
On Sat, Jan 31, 2015 at 3:39 PM, Jeff Squyres (jsquyres) wrote:
> Alina --
>
> Sorry; I think this bug report got lost in the run-up to the Open MPI dev
> meeting last week, and that fact that Nathan (the primary one-
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)
20 matches
Mail list logo
