Sounds good to me.
On Jul 21, 2008, at 9:52 AM, Jeff Squyres wrote:
Sorry for the late reply -- how about 3pm today (Monday)?
On Jul 18, 2008, at 3:55 PM, Ethan Mallove wrote:
I'm basically available except for 2-4p on Friday.
-Ethan
On Fri, Jul/18/2008 10:02:10AM, Josh Hursey wrote:
Yeah it might be good to touch base and see if there are any
burning fires
that we need to put out.
For me it would have to be either next week or most likely the end
of
August. :( The good news is that I don't have too much on my
calendar for
next week. I'm available (prefer earlier in the week):
M - Anytime
T - 12 - 2, 2-4
W - 10 - 11:30, 2 - 4
R - anytime
F - not available.
-- Josh
On Jul 18, 2008, at 9:29 AM, Jeff Squyres wrote:
Mebbe we should have a teleconf sometime in the not-distant
future and see
if we want to prioritize some of the pending MTT work...?
On Jul 17, 2008, at 6:39 PM, Ethan Mallove wrote:
On Thu, Jul/17/2008 04:35:38PM, Jeff Squyres wrote:
Here's a fun report (as of 17 July 2008):
http://www.open-mpi.org/mtt/index.php?do_redir=775
Note that two of the rows are in the future. :-) (Absoft has
since
fixed
the problem; ntp accidentally got turned off)
Ethan and I talked about this a bit, and then Josh and I talked
about
it.
Posting here to summarize everything:
- It seems like a good solution for the moment is for
submit.php to
examine
all the timestamps in a given submit and compare them to
now(). Find
the
timestamp that latest in time, and compute x=latest_timestamp -
now().
If
x>0, then subtract x from *all* timestamps in the submitted
data. Then
print a Big Hairy Warning on the client that their time is not
coordinated
with the server.
- Josh thinks that we should have a larger conversation about
how to
have
some values be regulated (e.g., MPI name, test suite name,
etc.). I
agree
-- classic case: some people call it "intel", others call it
"intelsuite".They show up differently in the DB. My $0.02 is
that we should
allow
people to call it whatever they want in the .ini file, but then
somehow
ensure to submit the names all consistently (e.g., ini file has
a map of
"this ini section is reported as 'intel'"), and if the name is
invalid,
reject the data from the DB (or maybe put it in "quarrantine"
so that it
can be cleaned up and put in the main DB)?
It's a neccessity that the INI section naming be flexible.
E.g., I have intel-32 and intel-64 sections to test 32-bit
and 64-bit. Note, there's no way around this because the
Perl INI parser we're using does not allow duplicate section
names, and also, MTT constructs a scratch tree on the
assumption that each section has a unique name.
For "database text string regulation", there's also:
http://svn.open-mpi.org/trac/mtt/ticket/7 (users should be
able to delete or modify results from database)
-Ethan
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
--
Jeff Squyres
Cisco Systems
_______________________________________________
mtt-devel mailing list
mtt-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
