Re: [OMPI devel] Proposal on RFCs

[Howard Pritchard]

HI Ralph,

Let's definitely discuss on 12/1.  Unless it's something like code deletion
or  large extern package update (like the PMIx 1.1 PR
or hwloc refresh), just opening a PR that touches like 100+ files across a
range of the code base needs more than the current github
PR interface provides.

I'd add that it would not hurt for proposals involving major changes/new
algorithms, etc. to have a wiki page.

Howard




2015-11-21 11:16 GMT-07:00 Ralph Castain :

> Hi folks
>
> When we moved to Github, we decided that we would use their “pull
> requests” to replace our RFC process. Our thinking at the time was that
> everyone would receive these, and so would know that something had been
> proposed.
>
> What we hadn’t really anticipated was the volume of PRs that would be
> generated. Quite frankly, it has become hard to sift thru them all to
> identify those that involve significant change from those involving minor
> bug fixes.
>
> Josh and I were kicking this around last week at SC’15, and after some
> consideration, I thought it makes sense to at least propose a couple of
> modifications that might help people to track what’s going on:
>
> (a) revive the RFC for significant changes. If the PR touches core code,
> or involves a change that exceeds an isolated bug fix, it would help if
> people announced it on the devel mailing list with “RFC” in the subject
> line, an explanation appropriate in length to the corresponding change, and
> a pointer to the PR. We should also include a “timeout” to indicate when
> this PR is intended to be committed, minus any expressed concerns. This
> would allow people to become aware of a proposed change that could impact
> them.
>
> (b) send a note to the devel mailing list indicating you are about to
> start working on a significant change to the code base. We generally do
> this on our weekly telecon, but not everyone can attend those. So rather
> than surprising folks with a PR out of the blue, it would be good to let
> the community know of your intentions so people can chime in with
> suggestions and contact you off-list about possibly contributing to the
> change. Besides, it might help to avoid having others committing
> conflicting changes during the effort.
>
> I figured we could discuss this on the next telecon (Dec 1st), but wanted
> to throw it out there for comment and advanced consideration.
>
> Ralph
>
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2015/11/18379.php

Re: [OMPI devel] Remote orted verbosity

[Aurélien Bouteiller]

Frederico, 

Just add -debug-daemons to the mpirun command options. 

Aurélien
--
Aurélien Bouteiller, Ph.D. ~~ https://icl.cs.utk.edu/~bouteill/ 

> Le 23 nov. 2015 à 08:55, Federico Reghenzani 
>  a écrit :
> 
> Hi!
> 
> Is there any way to get the output of OPAL_OUTPUT_VERBOSE on remote orteds? 
> (or write it to a local file?).
> 
> We tried with --mca orte_debug_verbose but it works only for the local 
> machine (= where mpirun is executed).
> 
> 
> Cheers,
> Federico
> 
> __
> Federico Reghenzani
> M.Eng. Student @ Politecnico di Milano
> Computer Science and Engineering
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/11/18383.php

[OMPI devel] Remote orted verbosity

[Federico Reghenzani]

Hi!

Is there any way to get the output of OPAL_OUTPUT_VERBOSE on remote orted*s*?
(or write it to a local file?).

We tried with *--mca orte_debug_verbose* but it works only for the local
machine (= where mpirun is executed).


Cheers,
Federico

__
Federico Reghenzani
M.Eng. Student @ Politecnico di Milano
Computer Science and Engineering