On Wed, Sep 17, 2014 at 8:06 AM, Jeff Squyres (jsquyres) wrote:
> I actually have the mapping already. The *only* ID that is preserved
> between the two will be who the ticket is assigned to.
You sent out email asking for SVN -> github ID mapping, but did NOT ask
about IDs for Trac users who a
On Sep 16, 2014, at 2:59 PM, Paul Hargrove wrote:
> So the instructions from your reply is "create a github account if you wish
> to continue filing tickets".
I think that summarizes it, yes.
> But don't you want/need the trac->github account mapping now to convert
> existing tickets?
> For i
Good points - I'd move it across then. If more people know about it, they might
start using it again.
On Sep 17, 2014, at 7:57 AM, Jeff Squyres (jsquyres) wrote:
> On Sep 17, 2014, at 10:47 AM, Ralph Castain wrote:
>
>> Question: does it need to be private?
>
> There are some grants under 2
On Sep 17, 2014, at 10:47 AM, Ralph Castain wrote:
> Question: does it need to be private?
There are some grants under 2004/funding that probably might not be appropriate
to be public. There might be a few other not-public things in there, too. I
don't think I care enough to make a full/comp
Question: does it need to be private? Initially, we were using it to
collaborate on papers prior to publication, but there are better ways to do
that now. As it stands, I believe it is more of an archive.
I occasionally troll it for material for presentations, though it is getting a
little long
Question for the developer community:
SHORT: Should I convert the private ompi-docs SVN to a private repo on Github?
MORE DETAIL:
The ompi-docs SVN is a private repo that was used heavily in the first several
years of the project for collaborating to write papers. In the past few years,
I thi
Do you have a reproducer you can share for testing this? I'm unable to get it
to happen on my machine, but maybe you have a test code that triggers it so I
can continue debugging
Ralph
On Sep 17, 2014, at 4:07 AM, Gilles Gouaillardet
wrote:
> Thanks Ralph,
>
> this is much better but there
Thanks Ralph,
this is much better but there is still a bug :
with the very same scenario i described earlier, vpid 2 does not send
its message to vpid 3 once the connection has been established.
i tried to debug it but i have been pretty unsuccessful so far ..
vpid 2 calls tcp_peer_connected and
