Re: [iola-conversion-tool] Bug when Adding a document to the tracker

Robert Sparks <> Thu, 23 February 2012 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9B1E21F85D2; Wed, 22 Feb 2012 19:20:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.478
X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YoYo9U7bKOCH; Wed, 22 Feb 2012 19:20:33 -0800 (PST)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id E742921F85D1; Wed, 22 Feb 2012 19:20:32 -0800 (PST)
Received: from unexplicable.local ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id q1N3KVsQ073247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Feb 2012 21:20:31 -0600 (CST) (envelope-from
Message-ID: <>
Date: Wed, 22 Feb 2012 21:20:31 -0600
From: Robert Sparks <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Russ Housley <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060308030004020602090303"
Received-SPF: pass ( is authenticated by a trusted mechanism)
Cc: Ole Laursen <>, The IESG <>,
Subject: Re: [iola-conversion-tool] Bug when Adding a document to the tracker
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Feb 2012 03:20:35 -0000

(Ole - question for you below)

Russ -

The existing code isn't displaying an area based on what was set on the 
edit-info form (and wasn't at the time that two-maturity-level was up 

Looking in the production system at the next telechat:

I see things like this:

        3.2.1 New Items

<> [txt] 
The Atom "deleted-entry" Element (Informational)
Token: Peter Saint-Andre (gen area)

I think you might have seen gen for Jari on -two-maturity-level as an 
artifact of whatever is causing gen to show
on that page.

In the trackerbeta, at <>, the 
same item looks like this:

        3.2.1 New Items

<> [txt] 
The Atom "deleted-entry" Element (Informational)
Token: Peter Saint-Andre (app area)

Ole - can you let us know why that shows as gen in the production system?

On 2/22/12 4:52 PM, Russ Housley wrote:
> This should not be true.  A telechat agenda indicates which AD has the 
> token, and it shows an Area.  I believe that when Jari was the token 
> holder for -two-maturity-level, the area was still "(Gen)".
> Russ
> On Feb 22, 2012, at 4:16 PM, Robert Sparks wrote:
>> IESG :
>> Cindy and I stumbled over what we first thought was a bug, but it 
>> turned out to be a surprising
>> feature/side-effect of the conversion effort.
>> The data we've been collecting on the edit-info-form (what we have 
>> been using to add a document to the
>> tracker or to change it's IESG state/telechat date, etc.) about which 
>> area a document belongs to is not being
>> used by any part of the production datatracker other than that form.
>> <ceficbhd.png>
>> So, it will not appear on the form in the new system (and the data 
>> collected in the old system is
>> not being migrated I believe).
>> That really surprised me, but after digging through the code and 
>> discussing it with Ole, I'm convinced it's
>> correct.
>> If we find a need to start collecting that data again in the future, 
>> it won't be hard to add.
>> RjS
>> On 2/22/12 11:18 AM, Ole Laursen wrote:
>>> 2012/2/21 Robert Sparks < 
>>> <>>
>>>     The biggest is that the form didn't ask for the area the
>>>     document should be associated with.
>>>     It occasionally happens that an AD from outside the area takes
>>>     the shepherd role for a document, so
>>>     you can't infer this from which AD is assigned.
>>> Right. At the moment, we don't store an area at all. Grepping for 
>>> it, the only place I managed to find using the attribute apart from 
>>> the edit form is the agenda document template where the 
>>> proxy wrapper will infer the area from the WG (if there's a WG) or 
>>> else from the shepherding AD.
>>> The search page looks for the area of the WG in the old schema if 
>>> you do a search for area, not the area attribute which is perhaps 
>>> not surprising if it's only set for documents in the IESG process.
>>> So do you think this is a problem still?
>> <snip/>