Re: [OMPI devel] [bug] One-sided communication with a duplicated datatype
George,
Thanks. I've confirmed your patch.
I wrote a simple program to test your patch and no problems are found.
The test program is attached to this mail.
Regards,
KAWASHIMA Takahiro
> Takahiro,
>
> Please find below another patch, this time hopefully fixing all issues. The
> problem with my original patch and with yours was that they try to address
> the packing of the data representation without fixing the computation of the
> required length. As a result the length on the packer and unpacker differs
> and the unpacking of the subsequent data is done from a wrong location.
>
> I changed the code to force the preparation of the packed data representation
> before returning the length the first time. This way we can compute exactly
> how many bytes we need, including the potential alignment requirements. As a
> result the amount on both sides (the packer and the unpacker) are now
> identical, and the entire process works flawlessly (or so I hope).
>
> Let me know if you still notice issues with this patch. I'll push the
> tomorrow in the trunk, so it can soak for a few days before propagation to
> the branches.
#include
#include
#include
#include
static MPI_Datatype types[100];
static MPI_Win win;
static int obuf[1], tbuf[100];
static void do_put(int expected, int index, char *description)
{
int i;
for (i = 1; types[i] != MPI_DATATYPE_NULL; i++);
i--;
if (i != 0) {
MPI_Type_commit(&types[i]);
}
memset(tbuf, 0, sizeof(tbuf));
MPI_Win_fence(0, win);
MPI_Put(obuf, 1, types[0], 0, 0, 1, types[i], win);
MPI_Win_fence(0, win);
if (tbuf[index] != expected) {
printf("NG %s (expected: %d, actual: %d, index: %d)\n",
description, expected, tbuf[index], index);
} else {
printf("OK %s\n", description);
}
for (i = 1; types[i] != MPI_DATATYPE_NULL; i++) {
MPI_Type_free(&types[i]);
}
}
int main(int argc, char *argv[])
{
int i;
int displs[] = {1};
int blens[] = {1};
types[0] = MPI_INT;
for (i = 1; i < sizeof(types) / sizeof(types[0]); i++) {
types[i] = MPI_DATATYPE_NULL;
}
obuf[0] = 77;
MPI_Init(&argc, &argv);
MPI_Win_create(tbuf, sizeof(tbuf[0]), sizeof(tbuf) / sizeof(tbuf[0]),
MPI_INFO_NULL, MPI_COMM_SELF, &win);
do_put(77, 0, "predefined");
MPI_Type_dup(types[0], &types[1]);
do_put(77, 0, "dup");
MPI_Type_contiguous(1, types[0], &types[1]);
do_put(77, 0, "contiguous");
MPI_Type_vector(1, 1, 1, types[0], &types[1]);
do_put(77, 0, "vector");
MPI_Type_indexed(1, blens, displs, types[0], &types[1]);
do_put(77, 1, "indexed");
MPI_Type_contiguous(1, types[0], &types[1]);
MPI_Type_dup(types[1], &types[2]);
do_put(77, 0, "contiguous+dup");
MPI_Type_dup(types[0], &types[1]);
MPI_Type_contiguous(1, types[1], &types[2]);
do_put(77, 0, "dup+contiguous");
MPI_Type_indexed(1, blens, displs, types[0], &types[1]);
MPI_Type_contiguous(1, types[1], &types[2]);
do_put(77, 1, "indexed+contiguous");
MPI_Type_contiguous(1, types[0], &types[1]);
MPI_Type_indexed(1, blens, displs, types[1], &types[2]);
do_put(77, 1, "contiguous+indexed");
MPI_Type_contiguous(1, types[0], &types[1]);
MPI_Type_dup(types[1], &types[2]);
MPI_Type_contiguous(1, types[2], &types[3]);
do_put(77, 0, "contiguous+dup+contiguous");
MPI_Type_dup(types[0], &types[1]);
MPI_Type_contiguous(1, types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
do_put(77, 0, "dup+contiguous+dup");
MPI_Type_dup(types[0], &types[1]);
MPI_Type_dup(types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
do_put(77, 0, "dup+dup+dup");
MPI_Type_indexed(1, blens, displs, types[0], &types[1]);
MPI_Type_contiguous(1, types[1], &types[2]);
MPI_Type_vector(1, 1, 1, types[2], &types[3]);
do_put(77, 1, "indexed+contiguous+vector");
MPI_Type_dup(types[0], &types[1]);
MPI_Type_contiguous(1, types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
MPI_Type_dup(types[3], &types[4]);
do_put(77, 0, "dup+contiguous+dup+dup");
MPI_Type_contiguous(1, types[0], &types[1]);
MPI_Type_dup(types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
MPI_Type_dup(types[3], &types[4]);
do_put(77, 0, "contiguous+dup+dup+dup");
MPI_Type_dup(types[0], &types[1]);
MPI_Type_dup(types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
MPI_Type_contiguous(1, types[3], &types[4]);
do_put(77, 0, "dup+dup+dup+contiguous");
MPI_Type_indexed(1, blens, displs, types[0], &types[1]);
MPI_Type_dup(types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
MPI_Type_contiguous(1, types[3], &types[4]);
do_put(77, 1, "indexed+dup+dup+contiguous");
MPI_Type_indexed(1, blens, displs, types[0], &types[1]);
MPI_Type_contiguous(1, types[1], &types[2]);
MPI_Type_dup(types[2], &types[3]);
MPI_Ty
Re: [OMPI devel] [bug] One-sided communication with a duplicated datatype
Thanks for testing it. It is now in trunk r28790. George. On Jul 15, 2013, at 12:29 , KAWASHIMA Takahiro wrote: > George, > > Thanks. I've confirmed your patch. > I wrote a simple program to test your patch and no problems are found. > The test program is attached to this mail. > > Regards, > KAWASHIMA Takahiro > >> Takahiro, >> >> Please find below another patch, this time hopefully fixing all issues. The >> problem with my original patch and with yours was that they try to address >> the packing of the data representation without fixing the computation of the >> required length. As a result the length on the packer and unpacker differs >> and the unpacking of the subsequent data is done from a wrong location. >> >> I changed the code to force the preparation of the packed data >> representation before returning the length the first time. This way we can >> compute exactly how many bytes we need, including the potential alignment >> requirements. As a result the amount on both sides (the packer and the >> unpacker) are now identical, and the entire process works flawlessly (or so >> I hope). >> >> Let me know if you still notice issues with this patch. I'll push the >> tomorrow in the trunk, so it can soak for a few days before propagation to >> the branches. > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: revised ORTE error handling
Ralph, Sorry for the late answer, we have quite a few things on our todo list right now. Here are few concerns I'm having about the proposed approach. 1. We would have preferred to have a list of processes for the ompi_errhandler_runtime_callback function. We don't necessary care about the error code, but having a list will allow us to move the notifications per bulk instead of one by one. 2. You made the registration of the callbacks ordered, and added special arguments to append or prepend callbacks to the list. Right now I can't figure out a good reason on how to use it especially that the order might be impose on the order the modules are loaded by the frameworks, thus not something we can easily control. 3. The callback list. The concept is useful, I don't know about the implementation. The current version doesn't support stopping the propagation of the error signal, which might be an issue in some cases. I can picture the fact that one level know about the issue, and know how to fix it, so the error does not need to propagate to other levels. This can be implemented in the old way interrupts were managed in DOS, with basically a simple _get / _set type of interface. If a callback wants to propagate the error it has first to retrieve the ancestor on the moment when it registered the callback and then explicitly calls it upon error. Again, nothing major in the short term as it will take a significant amount of work to move the only user of such error handling capability (the FT prototype) back over the current version of the ORTE. Regards, George. On Jul 3, 2013, at 06:45 , Ralph Castain wrote: > NOTICE: This RFC modifies the MPI-RTE interface > > WHAT: revise the RTE error handling to allow registration of callbacks upon > RTE-detected errors > > WHY: currently, the RTE aborts the process if an RTE-detected error occurs. > This allows the upper layers (e.g., MPI) no chance to implement their own > error response strategy, and it precludes allowing user-defined error > handling. > > TIMEOUT: let's go for July 19th, pending further discussion > > George and I were talking about ORTE's error handling the other day in > regards to the right way to deal with errors in the updated OOB. > Specifically, it seemed a bad idea for a library such as ORTE to be aborting > the job on its own prerogative. If we lose a connection or cannot send a > message, then we really should just report it upwards and let the application > and/or upper layers decide what to do about it. > > The current code base only allows a single error callback to exist, which > seemed unduly limiting. So, based on the conversation, I've modified the > errmgr interface to provide a mechanism for registering any number of error > handlers (this replaces the current "set_fault_callback" API). When an error > occurs, these handlers will be called in order until one responds that the > error has been "resolved" - i.e., no further action is required. The default > MPI layer error handler is specified to go "last" and calls mpi_abort, so the > current "abort" behavior is preserved unless other error handlers are > registered. > > In the register_callback function, I provide an "order" param so you can > specify "this callback must come first" or "this callback must come last". > Seemed to me that we will probably have different code areas registering > callbacks, and one might require it go first (the default "abort" will always > require it go last). So you can append and prepend, or go first/last. > > The errhandler callback function passes the name of the proc involved (which > can be yourself for internal errors) and the error code. This is a change > from the current fault callback which returned an opal_pointer_array of > process names. > > The work is available for review in my bitbucket: > > https://bitbucket.org/rhc/ompi-errmgr > > I've attached the svn diff as well. > > Appreciate your comments - nothing in concrete. > Ralph > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] RFC: revised ORTE error handling
On Jul 15, 2013, at 6:45 AM, George Bosilca wrote: > Ralph, > > Sorry for the late answer, we have quite a few things on our todo list right > now. Here are few concerns I'm having about the proposed approach. > > 1. We would have preferred to have a list of processes for the > ompi_errhandler_runtime_callback function. We don't necessary care about the > error code, but having a list will allow us to move the notifications per > bulk instead of one by one. No problem - I can easily make that change > > 2. You made the registration of the callbacks ordered, and added special > arguments to append or prepend callbacks to the list. Right now I can't > figure out a good reason on how to use it especially that the order might be > impose on the order the modules are loaded by the frameworks, thus not > something we can easily control. > > 3. The callback list. The concept is useful, I don't know about the > implementation. The current version doesn't support stopping the propagation > of the error signal, which might be an issue in some cases. I can picture the > fact that one level know about the issue, and know how to fix it, so the > error does not need to propagate to other levels. This can be implemented in > the old way interrupts were managed in DOS, with basically a simple _get / > _set type of interface. If a callback wants to propagate the error it has > first to retrieve the ancestor on the moment when it registered the callback > and then explicitly calls it upon error. > Yeah, these things bothered me too. I did it for only on reason. The current implementation does as you describe in terms of the caller maintaining ancestry. However, what if the first thing registered is the "abort" callback? Then how do you avoid having "abort" called early in the process, not giving other callbacks a chance to attempt to continue? So I started with two registration calls - one for a default, and the other for anything else. Then it occurred to me that someone might want a "prologue" handler - e.g., start the error handling by blocking the injection of any more messages until we know what the problem is. So I added a registration for a prologue. I now had registrations for a prologue, an epilogue, and a regular callback. So I just generalized it, figuring that someone could ignore the ordering and just add callbacks if they wanted to, but leaving the ability to specify "go first" and "go last". I don't honestly have anything specific in mind for it, but that was the reasoning. I added the ability to stop processing callbacks (a return of OMPI_SUCCESS will stop it), so that is there. Any preferences? > Again, nothing major in the short term as it will take a significant amount > of work to move the only user of such error handling capability (the FT > prototype) back over the current version of the ORTE. > > Regards, > George. > > > > On Jul 3, 2013, at 06:45 , Ralph Castain wrote: > >> NOTICE: This RFC modifies the MPI-RTE interface >> >> WHAT: revise the RTE error handling to allow registration of callbacks upon >> RTE-detected errors >> >> WHY: currently, the RTE aborts the process if an RTE-detected error occurs. >> This allows the upper layers (e.g., MPI) no chance to implement their own >> error response strategy, and it precludes allowing user-defined error >> handling. >> >> TIMEOUT: let's go for July 19th, pending further discussion >> >> George and I were talking about ORTE's error handling the other day in >> regards to the right way to deal with errors in the updated OOB. >> Specifically, it seemed a bad idea for a library such as ORTE to be aborting >> the job on its own prerogative. If we lose a connection or cannot send a >> message, then we really should just report it upwards and let the >> application and/or upper layers decide what to do about it. >> >> The current code base only allows a single error callback to exist, which >> seemed unduly limiting. So, based on the conversation, I've modified the >> errmgr interface to provide a mechanism for registering any number of error >> handlers (this replaces the current "set_fault_callback" API). When an error >> occurs, these handlers will be called in order until one responds that the >> error has been "resolved" - i.e., no further action is required. The default >> MPI layer error handler is specified to go "last" and calls mpi_abort, so >> the current "abort" behavior is preserved unless other error handlers are >> registered. >> >> In the register_callback function, I provide an "order" param so you can >> specify "this callback must come first" or "this callback must come last". >> Seemed to me that we will probably have different code areas registering >> callbacks, and one might require it go first (the default "abort" will >> always require it go last). So you can append and prepend, or go first/last. >> >> The errhandler callback function passes
Re: [OMPI devel] RFC: revised ORTE error handling
Thanks for adding the capability to stop processing the callbacks. For the rest I have no preferences, lets move forward with what's in there and adapt if new needs appear. Thanks, George. On Jul 15, 2013, at 16:05 , Ralph Castain wrote: > > On Jul 15, 2013, at 6:45 AM, George Bosilca wrote: > >> Ralph, >> >> Sorry for the late answer, we have quite a few things on our todo list right >> now. Here are few concerns I'm having about the proposed approach. >> >> 1. We would have preferred to have a list of processes for the >> ompi_errhandler_runtime_callback function. We don't necessary care about the >> error code, but having a list will allow us to move the notifications per >> bulk instead of one by one. > > No problem - I can easily make that change > >> >> 2. You made the registration of the callbacks ordered, and added special >> arguments to append or prepend callbacks to the list. Right now I can't >> figure out a good reason on how to use it especially that the order might be >> impose on the order the modules are loaded by the frameworks, thus not >> something we can easily control. >> >> 3. The callback list. The concept is useful, I don't know about the >> implementation. The current version doesn't support stopping the propagation >> of the error signal, which might be an issue in some cases. I can picture >> the fact that one level know about the issue, and know how to fix it, so the >> error does not need to propagate to other levels. This can be implemented in >> the old way interrupts were managed in DOS, with basically a simple _get / >> _set type of interface. If a callback wants to propagate the error it has >> first to retrieve the ancestor on the moment when it registered the callback >> and then explicitly calls it upon error. >> > > Yeah, these things bothered me too. I did it for only on reason. The current > implementation does as you describe in terms of the caller maintaining > ancestry. However, what if the first thing registered is the "abort" > callback? Then how do you avoid having "abort" called early in the process, > not giving other callbacks a chance to attempt to continue? > > So I started with two registration calls - one for a default, and the other > for anything else. Then it occurred to me that someone might want a > "prologue" handler - e.g., start the error handling by blocking the injection > of any more messages until we know what the problem is. So I added a > registration for a prologue. > > I now had registrations for a prologue, an epilogue, and a regular callback. > So I just generalized it, figuring that someone could ignore the ordering and > just add callbacks if they wanted to, but leaving the ability to specify "go > first" and "go last". > > I don't honestly have anything specific in mind for it, but that was the > reasoning. I added the ability to stop processing callbacks (a return of > OMPI_SUCCESS will stop it), so that is there. > > Any preferences? > >> Again, nothing major in the short term as it will take a significant amount >> of work to move the only user of such error handling capability (the FT >> prototype) back over the current version of the ORTE. >> >> Regards, >> George. >> >> >> >> On Jul 3, 2013, at 06:45 , Ralph Castain wrote: >> >>> NOTICE: This RFC modifies the MPI-RTE interface >>> >>> WHAT: revise the RTE error handling to allow registration of callbacks upon >>> RTE-detected errors >>> >>> WHY: currently, the RTE aborts the process if an RTE-detected error occurs. >>> This allows the upper layers (e.g., MPI) no chance to implement their own >>> error response strategy, and it precludes allowing user-defined error >>> handling. >>> >>> TIMEOUT: let's go for July 19th, pending further discussion >>> >>> George and I were talking about ORTE's error handling the other day in >>> regards to the right way to deal with errors in the updated OOB. >>> Specifically, it seemed a bad idea for a library such as ORTE to be >>> aborting the job on its own prerogative. If we lose a connection or cannot >>> send a message, then we really should just report it upwards and let the >>> application and/or upper layers decide what to do about it. >>> >>> The current code base only allows a single error callback to exist, which >>> seemed unduly limiting. So, based on the conversation, I've modified the >>> errmgr interface to provide a mechanism for registering any number of error >>> handlers (this replaces the current "set_fault_callback" API). When an >>> error occurs, these handlers will be called in order until one responds >>> that the error has been "resolved" - i.e., no further action is required. >>> The default MPI layer error handler is specified to go "last" and calls >>> mpi_abort, so the current "abort" behavior is preserved unless other error >>> handlers are registered. >>> >>> In the register_callback function, I provide an "order
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
The following accounts were removed by request: REMOVE timattox: Tim Mattox **NO COMMITS IN LAST YEAR** REMOVE lennyve: Lenny Verkhovsky **NO COMMITS IN LAST YEAR** REMOVE yaeld:Yael Dayan REMOVE rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** REMOVE wbland: Wesley Bland **NO COMMITS IN LAST YEAR** REMOVE shiqing: Shiqing Fan REMOVE arougier: Antoine Rougier REMOVE emallove: Ethan Mallove **NO COMMITS IN LAST YEAR** REMOVE memoryhole:Kyle Wheeler **NO COMMITS IN LAST YEAR** REMOVE tdd: Terry Dontje The following accounts timed out due to lack of response, and have been deleted. I suspect that at least some of these will realize their error later and send me a panicked/confused email in the future asking why they can't commit. :-) rusraink: Rainer Keller **NO COMMITS IN LAST YEAR** lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** adkulkar: Abhishek Kulkarni afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** cyeoh:Chris Yeoh bbenton: Brad Benton tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** swise:Steve Wise On Jul 8, 2013, at 6:32 PM, Jeff Squyres (jsquyres) wrote: > According to https://svn.open-mpi.org/trac/ompi/wiki/Admistrative%20rules, it > is time for our annual review of Open MPI SVN accounts of these SVN repos: > hwloc, mtt, ompi-docs, ompi-tests, ompi-www, ompi. > > *** Organizations must reply by COB Friday, 12 July, 2013 *** > *** No reply means: delete all of my organization's SVN accounts > > Each organization must reply and specify which of their accounts can stay and > which should go. I cross-referenced the SVN logs from all of our SVN > repositories to see who has not committed anything in the past year. > > *** I strongly recommend deleting accounts who have not committed in the last > year. > *** Other accounts can be deleted, too (e.g., those who have left a given > organization). > > bakeyournoodle.com (???) > == > tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** > > Cisco > = > dgoodell: Dave Goodell > jsquyres: Jeff Squyres > > Indiana > == > lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** > adkulkar: Abhishek Kulkarni > afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** > timattox: Tim Mattox **NO COMMITS IN LAST YEAR** > > U. Houston > = > edgar:Edgar Gabriel > vvenkatesan:Vishwanath Venkatesan > > Mellanox > == > alekseys: Aleksey Senin > kliteyn: Yevgeny Kliteynik > miked:Mike Dubman > lennyve: Lenny Verkhovsky **NO COMMITS IN LAST > YEAR** > yaeld:Yael Dayan > vasily: Vasily Philipov > amikheev: Alex Mikheev > alex: Alexander Margolin > alinas: Alina Sklarevich **NO COMMITS IN LAST YEAR** > igoru:Igor Usarov > jladd:Joshua Ladd > yosefe: Yossi > rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** > > Tennessee > > bosilca: George Bosilca > bouteill: Aurelien Bouteiller > wbland: Wesley Bland **NO COMMITS IN LAST YEAR** > > hlrs.de > === > shiqing: Shiqing Fan > hpcchris: Christoph Niethammer > rusraink: Rainer Keller **NO COMMITS IN LAST > YEAR** > > IBM > == > jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** > cyeoh:Chris Yeoh > bbenton: Brad Benton > > INRIA > > bgoglin: Brice Goglin > arougier: Antoine Rougier > sthibaul: Samuel Thibault > mercier: Guillaume Mercier **NO COMMITS IN LAST YEAR** > nfurmento:Nathalie Furmento **NO COMMITS IN LAST > YEAR** > herault: Thomas Herault **NO COMMITS IN LAST YEAR** > > LANL > > hjelmn: Nathan Hjelm > samuel: Samuel K. Gutierrez > > NVIDIA > == > rolfv:Rolf Vandevaart > > U. Wisconsin La Crosse > > jjhursey: Joshua Hursey > > Intel > > rhc: Ralph Castain > > Chelsio / OGC > = > swise:Steve Wise > > Oracle > == > emallove: Ethan Mallove **NO COMMITS IN LAST YEAR** > eugene: Eugene Loh > tdd: Terry Dontje > > ORNL > > manjugv: Manjunath, Gorentla Venkata > naughtont:Thomas Naughton > pasha:Pavel Shamis > > Sandia > == > brbarret: Brian Barrett > memoryhole:Kyle Wheeler **NO COMMITS IN LAST YEAR** > ktpedre: Kevin Pedretti **NO COMMITS IN LAST YEAR** > mjleven: Michael Levenhagen **NO COMMITS IN LAST YEAR** > rbbrigh: Ron Brightwell **NO COMMITS IN LAST YEAR** > > Dresden > = > knuepfer: Andreas Knuepfer **NO COMMITS IN > LAST YEAR** > bwesarg: Bert Wesarg **NO COMMITS IN LAST YEAR** > jurenz: Matthias Jurenz > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
Please do not remove me. I will continue to support chelsio/iwarp in open mpi. Thanks, Steve. On 7/15/2013 1:12 PM, Jeff Squyres (jsquyres) wrote: The following accounts were removed by request: REMOVE timattox: Tim Mattox **NO COMMITS IN LAST YEAR** REMOVE lennyve: Lenny Verkhovsky **NO COMMITS IN LAST YEAR** REMOVE yaeld:Yael Dayan REMOVE rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** REMOVE wbland: Wesley Bland **NO COMMITS IN LAST YEAR** REMOVE shiqing: Shiqing Fan REMOVE arougier: Antoine Rougier REMOVE emallove: Ethan Mallove **NO COMMITS IN LAST YEAR** REMOVE memoryhole:Kyle Wheeler **NO COMMITS IN LAST YEAR** REMOVE tdd: Terry Dontje The following accounts timed out due to lack of response, and have been deleted. I suspect that at least some of these will realize their error later and send me a panicked/confused email in the future asking why they can't commit. :-) rusraink: Rainer Keller **NO COMMITS IN LAST YEAR** lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** adkulkar: Abhishek Kulkarni afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** cyeoh:Chris Yeoh bbenton: Brad Benton tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** swise:Steve Wise On Jul 8, 2013, at 6:32 PM, Jeff Squyres (jsquyres) wrote: According to https://svn.open-mpi.org/trac/ompi/wiki/Admistrative%20rules, it is time for our annual review of Open MPI SVN accounts of these SVN repos: hwloc, mtt, ompi-docs, ompi-tests, ompi-www, ompi. *** Organizations must reply by COB Friday, 12 July, 2013 *** *** No reply means: delete all of my organization's SVN accounts Each organization must reply and specify which of their accounts can stay and which should go. I cross-referenced the SVN logs from all of our SVN repositories to see who has not committed anything in the past year. *** I strongly recommend deleting accounts who have not committed in the last year. *** Other accounts can be deleted, too (e.g., those who have left a given organization). bakeyournoodle.com (???) == tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** Cisco = dgoodell: Dave Goodell jsquyres: Jeff Squyres Indiana == lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** adkulkar: Abhishek Kulkarni afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** timattox: Tim Mattox **NO COMMITS IN LAST YEAR** U. Houston = edgar:Edgar Gabriel vvenkatesan:Vishwanath Venkatesan Mellanox == alekseys: Aleksey Senin kliteyn: Yevgeny Kliteynik miked:Mike Dubman lennyve: Lenny Verkhovsky **NO COMMITS IN LAST YEAR** yaeld:Yael Dayan vasily: Vasily Philipov amikheev: Alex Mikheev alex: Alexander Margolin alinas: Alina Sklarevich **NO COMMITS IN LAST YEAR** igoru:Igor Usarov jladd:Joshua Ladd yosefe: Yossi rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** Tennessee bosilca: George Bosilca bouteill: Aurelien Bouteiller wbland: Wesley Bland **NO COMMITS IN LAST YEAR** hlrs.de === shiqing: Shiqing Fan hpcchris: Christoph Niethammer rusraink: Rainer Keller **NO COMMITS IN LAST YEAR** IBM == jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** cyeoh:Chris Yeoh bbenton: Brad Benton INRIA bgoglin: Brice Goglin arougier: Antoine Rougier sthibaul: Samuel Thibault mercier: Guillaume Mercier **NO COMMITS IN LAST YEAR** nfurmento:Nathalie Furmento **NO COMMITS IN LAST YEAR** herault: Thomas Herault **NO COMMITS IN LAST YEAR** LANL hjelmn: Nathan Hjelm samuel: Samuel K. Gutierrez NVIDIA == rolfv:Rolf Vandevaart U. Wisconsin La Crosse jjhursey: Joshua Hursey Intel rhc: Ralph Castain Chelsio / OGC = swise:Steve Wise Oracle == emallove: Ethan Mallove **NO COMMITS IN LAST YEAR** eugene: Eugene Loh tdd: Terry Dontje ORNL manjugv: Manjunath, Gorentla Venkata naughtont:Thomas Naughton pasha:Pavel Shamis Sandia == brbarret: Brian Barrett memoryhole:Kyle Wheeler **NO COMMITS IN LAST YEAR** ktpedre: Kevin Pedretti **NO COMMITS IN LAST YEAR** mjleven: Michael Levenhagen **NO COMMITS IN LAST YEAR** rbbrigh: Ron Brightwell **NO COMMITS IN LAST YEAR** Dresden = knuepfer: Andreas Knuepfer **NO COMMITS IN LAST YEAR** bwesarg: Bert Wesarg **NO COMMITS IN LAST YEAR** jurenz: Matthias Jurenz -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Annual OMPI membership review: SVN accounts
You've been re-added. Thanks! On Jul 15, 2013, at 3:23 PM, Steve Wise wrote: > Please do not remove me. I will continue to support chelsio/iwarp in open > mpi. > > Thanks, > > Steve. > > On 7/15/2013 1:12 PM, Jeff Squyres (jsquyres) wrote: >> The following accounts were removed by request: >> >> REMOVE timattox: Tim Mattox **NO COMMITS IN LAST >> YEAR** >> REMOVE lennyve: Lenny Verkhovsky **NO COMMITS >> IN LAST YEAR** >> REMOVE yaeld:Yael Dayan >> REMOVE rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** >> REMOVE wbland: Wesley Bland **NO COMMITS IN LAST >> YEAR** >> REMOVE shiqing: Shiqing Fan >> REMOVE arougier: Antoine Rougier >> REMOVE emallove: Ethan Mallove **NO COMMITS IN >> LAST YEAR** >> REMOVE memoryhole:Kyle Wheeler **NO COMMITS IN LAST >> YEAR** >> REMOVE tdd: Terry Dontje >> >> The following accounts timed out due to lack of response, and have been >> deleted. I suspect that at least some of these will realize their error >> later and send me a panicked/confused email in the future asking why they >> can't commit. :-) >> >> rusraink: Rainer Keller **NO COMMITS IN >> LAST YEAR** >> lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** >> adkulkar: Abhishek Kulkarni >> afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** >> jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** >> cyeoh:Chris Yeoh >> bbenton: Brad Benton >> tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** >> swise:Steve Wise >> >> >> >> On Jul 8, 2013, at 6:32 PM, Jeff Squyres (jsquyres) >> wrote: >> >>> According to https://svn.open-mpi.org/trac/ompi/wiki/Admistrative%20rules, >>> it is time for our annual review of Open MPI SVN accounts of these SVN >>> repos: hwloc, mtt, ompi-docs, ompi-tests, ompi-www, ompi. >>> >>> *** Organizations must reply by COB Friday, 12 July, 2013 *** >>> *** No reply means: delete all of my organization's SVN accounts >>> >>> Each organization must reply and specify which of their accounts can stay >>> and which should go. I cross-referenced the SVN logs from all of our SVN >>> repositories to see who has not committed anything in the past year. >>> >>> *** I strongly recommend deleting accounts who have not committed in the >>> last year. >>> *** Other accounts can be deleted, too (e.g., those who have left a given >>> organization). >>> >>> bakeyournoodle.com (???) >>> == >>> tonyb:Tony Breeds **NO COMMITS IN LAST YEAR** >>> >>> Cisco >>> = >>> dgoodell: Dave Goodell >>> jsquyres: Jeff Squyres >>> >>> Indiana >>> == >>> lums: Andrew Lumsdaine **NO COMMITS IN LAST YEAR** >>> adkulkar: Abhishek Kulkarni >>> afriedle: Andrew Friedley **NO COMMITS IN LAST YEAR** >>> timattox: Tim Mattox **NO COMMITS IN LAST YEAR** >>> >>> U. Houston >>> = >>> edgar:Edgar Gabriel >>> vvenkatesan:Vishwanath Venkatesan >>> >>> Mellanox >>> == >>> alekseys: Aleksey Senin >>> kliteyn: Yevgeny Kliteynik >>> miked:Mike Dubman >>> lennyve: Lenny Verkhovsky **NO COMMITS IN >>> LAST YEAR** >>> yaeld:Yael Dayan >>> vasily: Vasily Philipov >>> amikheev: Alex Mikheev >>> alex: Alexander Margolin >>> alinas: Alina Sklarevich **NO COMMITS IN LAST YEAR** >>> igoru:Igor Usarov >>> jladd:Joshua Ladd >>> yosefe: Yossi >>> rlgraham: Rich Graham **NO COMMITS IN LAST YEAR** >>> >>> Tennessee >>> >>> bosilca: George Bosilca >>> bouteill: Aurelien Bouteiller >>> wbland: Wesley Bland **NO COMMITS IN LAST YEAR** >>> >>> hlrs.de >>> === >>> shiqing: Shiqing Fan >>> hpcchris: Christoph Niethammer >>> rusraink: Rainer Keller **NO COMMITS IN >>> LAST YEAR** >>> >>> IBM >>> == >>> jnysal: Nysal Jan K A **NO COMMITS IN LAST YEAR** >>> cyeoh:Chris Yeoh >>> bbenton: Brad Benton >>> >>> INRIA >>> >>> bgoglin: Brice Goglin >>> arougier: Antoine Rougier >>> sthibaul: Samuel Thibault >>> mercier: Guillaume Mercier **NO COMMITS IN LAST YEAR** >>> nfurmento:Nathalie Furmento **NO COMMITS IN >>> LAST YEAR** >>> herault: Thomas Herault **NO COMMITS IN LAST YEAR** >>> >>> LANL >>> >>> hjelmn: Nathan Hjelm >>> samuel: Samuel K. Gutierrez >>> >>> NVIDIA >>> == >>> rolfv:Rolf Vandevaart >>> >>> U. Wisconsin La Crosse >>> >>> jjhursey: Joshua Hursey >>> >>> Intel >>> >>> rhc: Ralph Castain >>> >>> Chelsio / OGC >>> = >>> swise:Steve Wise >>> >>> Oracle >>> == >>> emallove: Ethan Mallove **NO COMMITS IN LAST >>> YEAR** >>> eugene: Eugene Loh >>> tdd: Terry Dontje >>> >>> ORNL >>> >>> manjugv: Manjunath, Gorentla Venkata >>> naughtont:Thomas Naughton >>> pasha:Pavel Shamis >>> >>> Sandia >>> == >>> brbarret: Brian Barrett >>> memoryhole:Kyle Wheeler **NO COMMITS IN LAST YEAR** >>> ktpedre: Kevin Pedretti **NO COMMITS IN LAST YEAR** >>> mjleven: Michae
