This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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.
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):
>>> 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.
>>> print a Big Hairy Warning on the client that their time is not
>>> 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
>>> "intel suite".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
>>> 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
>>> 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)
>>> Jeff Squyres
>>> Cisco Systems
>>> mtt-devel mailing list
>> mtt-devel mailing list
> Jeff Squyres
> Cisco Systems
> mtt-devel mailing list