Re: [iola-conversion-tool] Bug when Adding a document to the tracker
Robert Sparks <rjsparks@nostrum.com> Thu, 23 February 2012 03:20 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: iola-conversion-tool@ietfa.amsl.com
Delivered-To: iola-conversion-tool@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B1E21F85D2; Wed, 22 Feb 2012 19:20:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.478
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoYo9U7bKOCH; Wed, 22 Feb 2012 19:20:33 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E742921F85D1; Wed, 22 Feb 2012 19:20:32 -0800 (PST)
Received: from unexplicable.local (pool-71-170-125-181.dllstx.fios.verizon.net [71.170.125.181]) (authenticated bits=0) by nostrum.com (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 rjsparks@nostrum.com)
Message-ID: <4F45B07F.7080508@nostrum.com>
Date: Wed, 22 Feb 2012 21:20:31 -0600
From: Robert Sparks <rjsparks@nostrum.com>
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 <housley@vigilsec.com>
References: <4F4415E7.9080608@nostrum.com> <CANb2OvKXRUarNY-Vp+CkA+7P5FZ1=_OfqyO67gOnKfx2bAARCQ@mail.gmail.com> <4F455B47.3040305@nostrum.com> <F3883977-5295-48A7-A226-ABCA5563A2A3@vigilsec.com>
In-Reply-To: <F3883977-5295-48A7-A226-ABCA5563A2A3@vigilsec.com>
Content-Type: multipart/alternative; boundary="------------060308030004020602090303"
Received-SPF: pass (nostrum.com: 71.170.125.181 is authenticated by a trusted mechanism)
Cc: Ole Laursen <olau@iola.dk>, The IESG <iesg@ietf.org>, iola-conversion-tool@ietf.org
Subject: Re: [iola-conversion-tool] Bug when Adding a document to the tracker
X-BeenThere: iola-conversion-tool@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of the IOLA / DB Schema Conversion Tool Project <iola-conversion-tool.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iola-conversion-tool>
List-Post: <mailto:iola-conversion-tool@ietf.org>
List-Help: <mailto:iola-conversion-tool-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iola-conversion-tool>, <mailto:iola-conversion-tool-request@ietf.org?subject=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 afaict). Looking in the production system at the next telechat: <https://datatracker.ietf.org/iesg/agenda/> I see things like this: 3.2.1 New Items draft-snell-atompub-tombstones <https://datatracker.ietf.org/doc/draft-snell-atompub-tombstones/> [txt] <http://www.ietf.org/id/draft-snell-atompub-tombstones-14.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 <http://trackerbeta.ietf.org/iesg/agenda/>, the same item looks like this: 3.2.1 New Items draft-snell-atompub-tombstones <http://trackerbeta.ietf.org/doc/draft-snell-atompub-tombstones/> [txt] <http://www.ietf.org/id/draft-snell-atompub-tombstones-14.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 <rjsparks@nostrum.com >>> <mailto:rjsparks@nostrum.com>> >>> >>> 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/> >
- [iola-conversion-tool] Bug when Adding a document… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Ole Laursen
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Ole Laursen
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Russ Housley
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Ole Laursen
- Re: [iola-conversion-tool] Bug when Adding a docu… Henrik Levkowetz
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Russ Housley
- Re: [iola-conversion-tool] Bug when Adding a docu… Sean Turner
- Re: [iola-conversion-tool] Bug when Adding a docu… Ole Laursen
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Russ Housley
- Re: [iola-conversion-tool] Bug when Adding a docu… Henrik Levkowetz
- Re: [iola-conversion-tool] Bug when Adding a docu… Henrik Levkowetz
- Re: [iola-conversion-tool] Bug when Adding a docu… Henrik Levkowetz
- Re: [iola-conversion-tool] Bug when Adding a docu… Robert Sparks
- Re: [iola-conversion-tool] Bug when Adding a docu… Henrik Levkowetz