Re: [codec] draft test and processing plan for the IETF Codec

Ron <ron@debian.org> Wed, 13 April 2011 20:40 UTC

Return-Path: <ron@debian.org>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C28B9E0839 for <codec@ietfc.amsl.com>; Wed, 13 Apr 2011 13:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4DNZYttF9Vl for <codec@ietfc.amsl.com>; Wed, 13 Apr 2011 13:40:41 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by ietfc.amsl.com (Postfix) with ESMTP id 0C195E05F5 for <codec@ietf.org>; Wed, 13 Apr 2011 13:40:40 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar0HAJ0Hpk120qsf/2dsb2JhbACYbY0zeMMihW4EhViIEA
Received: from ppp118-210-171-31.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.171.31]) by ipmail06.adl2.internode.on.net with ESMTP; 14 Apr 2011 06:10:38 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 430854F8F3 for <codec@ietf.org>; Thu, 14 Apr 2011 06:05:12 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iyEB5SVfKwXB for <codec@ietf.org>; Thu, 14 Apr 2011 06:05:09 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 972BD4F8FE; Thu, 14 Apr 2011 06:05:09 +0930 (CST)
Date: Thu, 14 Apr 2011 06:05:09 +0930
From: Ron <ron@debian.org>
To: codec@ietf.org
Message-ID: <20110413203509.GU30415@audi.shelbyville.oz>
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <4DA5A748.2050401@fas.harvard.edu> <027A93CE4A670242BD91A44E37105AEF17ACA9B583@ESESSCMS0351.eemea.ericsson.se> <4DA5D328.3060504@stpeter.im> <BANLkTi=DkC8HFSFzQ8q=xWU+zVL7D_aazA@mail.gmail.com> <4DA5E653.3020002@stpeter.im> <BANLkTik=NwZw5Ffk90+DBSoFSboF-XbQ+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BANLkTik=NwZw5Ffk90+DBSoFSboF-XbQ+g@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [codec] draft test and processing plan for the IETF Codec
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Apr 2011 20:40:44 -0000

On Wed, Apr 13, 2011 at 02:39:26PM -0400, Stephen Botzko wrote:
> On Wed, Apr 13, 2011 at 2:07 PM, Peter Saint-Andre <stpeter@stpeter.im>wrote:
> >
> > My opinion is that delaying forever would be bad.
>
> 
> I think everyone would agree.
> 
> In context, there appears to be some time to work through the formal testing
> w/o significant delays in publication, since the codec isn't finished yet,
> and we can potentially overlap some of the testing schedule with the
> publication process time.
> Make sense?

You could pick some tractable number of the ones that you think will
be the most enlightening and run some quick informal tests on those.

We can then take guidance from that as to whether more detailed tests
are warranted for those things, or whether we can agree the result is
clear from even a first approximation.  (and perhaps focus energy on
some different set of potentially more valuable tests instead of
chasing clear dead ends in great detail prematurely)

We are in soft-freeze of the bitstream.  So finding such cases,
if they do exist, would be much better sooner than later.

Doing as much as we can in parallel is clearly the best option.

Cheers,
Ron