[hwloc-devel] Create success (hwloc git 1.10.1-2-ge023792)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.10.1-2-ge023792 Start time: Thu Feb 5 21:07:34 EST 2015 End time: Thu Feb 5 21:09:04 EST 2015 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git 1.9.1-31-g988ee53)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.9.1-31-g988ee53 Start time: Thu Feb 5 21:06:00 EST 2015 End time: Thu Feb 5 21:07:33 EST 2015 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git 1.8.1-21-g21bb02e)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.8.1-21-g21bb02e Start time: Thu Feb 5 21:04:25 EST 2015 End time: Thu Feb 5 21:06:00 EST 2015 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git 1.7.2-43-g0fd264a)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc 1.7.2-43-g0fd264a Start time: Thu Feb 5 21:02:56 EST 2015 End time: Thu Feb 5 21:04:25 EST 2015 Your friendly daemon, Cyrador

[hwloc-devel] Create success (hwloc git dev-386-g557cb2f)

Creating nightly hwloc snapshot git tarball was a success. Snapshot: hwloc dev-386-g557cb2f Start time: Thu Feb 5 21:01:02 EST 2015 End time: Thu Feb 5 21:02:56 EST 2015 Your friendly daemon, Cyrador

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] turning the bot on for ompi-release?

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

Re: [OMPI devel] omni-release Github comment bot

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,

Re: [OMPI devel] omni-release Github comment bot

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

[OMPI devel] turning the bot on for ompi-release?

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] segmentation fault on an accumulate-fence test

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

Re: [OMPI devel] omni-release Github comment bot

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 ...? >

Re: [OMPI devel] segmentation fault on an accumulate-fence test

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

Re: [OMPI devel] omni-release Github comment bot

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

Re: [OMPI devel] omni-release Github comment bot

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,