search

LLNL / LaunchMON

LaunchMON is a software infrastructure that enables HPC run-time tools to co-locate tool daemons with a parallel job. Its API allows a tool to identify all the remote processes of a job and to scalably launch daemons into the relevant nodes.
Other
13 stars 9 forks source link

Adapt Cray's pending PR to the new base #13

Closed dongahn closed 8 years ago

dongahn commented 8 years ago

We need to incorporate Cray's PR #7 into the new base with PR #12. It seems it would be most sensible to handpick the relevant changes and created a new PR.

tgamblin commented 8 years ago

They both look like they merge cleanly -- why not merge #7 then merge #12 and resolve any conflicts...?

dongahn commented 8 years ago

That is a reasonable idea. What should have done was to merge #7 first and rework for #12.

I am not sure how much work will be needed to rebase to the new master if #7 is merged first with all the changes maded in #12.

Will do some testing next week.

tgamblin commented 8 years ago

@dongahn: is LaunchMon using a rebase workflow? You don't really have to rebase. I find that it's often less work to fix things once in a merge commit than to rewrite history, but if you insist on a rebase workflow then you probably want to do this: git config --global rerere.enabled 1. I find that helps a lot for avoiding the same conflict multiple times. See this blog post.

dongahn commented 8 years ago

Launchmon hasn't had strict protocols. After it grew about of a research project from source forge.

On a github repo, I tend to like rebasing because there commit history looks cleaner. I heard about rerere and thanks for the blog!

Dong

From: Todd Gamblin Sent: Sunday, May 01, 2016 7:45:32 PM To: LLNL/LaunchMON Cc: Ahn, Dong H.; Mention Subject: Re: [LLNL/LaunchMON] Adapt Cray's pending PR to the new base (#13)

@dongahnhttps://github.com/dongahn: is LaunchMon using a rebase workflow? You don't really have to rebase. I find that it's often less work to fix things once in a merge commit than to rewrite history, but if you insist on a rebase workflow then you probably want to do this: git config --global rerere.enabled 1. I find that helps a lot for avoiding the same conflict multiple times. See this blog posthttps://medium.com/@porteneuve/fix-conflicts-only-once-with-git-rerere-7d116b2cec67#.wn78lbr83

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHubhttps://github.com/LLNL/LaunchMON/issues/13#issuecomment-216095783

agontarek commented 8 years ago

Hi all. I can have either Bob or Alex take a look at this. Note that we also have quite a few additional changes and bugfixes for CTI (Cray Tools Interface), a release of CTI is forthcoming. I am hoping that Bob/Alex is able to create a new pull request with these changes once CTI is released.

Note that I am no longer in the debugging tools group. I am now in the compiler group working on PGAS languages.

dongahn commented 8 years ago

@agontarek: Thanks!

If Bob and Alex have github IDs we can refer them here.

What would be nice is if Cray folks can give a quick review for #20, we can merge that in first. I believe the change is reasonable and doesn't break any other environment so this should be an easy merge.

Then, new PRs can be created and submitted on top of the new master? I don't want to lose this initial support in case we want to backport something from there or trying this on older systems...

dongahn commented 8 years ago

BTW, good luck with your PGAS project :-)

dongahn commented 8 years ago

We took liberty to merge this in. If Cray sees issues, we can always reopen the case.