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

Henrik Levkowetz <henrik@levkowetz.com> Thu, 23 February 2012 22:08 UTC

Return-Path: <henrik@levkowetz.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 5B0FF21F8752 for <iola-conversion-tool@ietfa.amsl.com>; Thu, 23 Feb 2012 14:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.284
X-Spam-Level:
X-Spam-Status: No, score=-102.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 CcRyGtNx5pyK for <iola-conversion-tool@ietfa.amsl.com>; Thu, 23 Feb 2012 14:08:55 -0800 (PST)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7943521F8545 for <iola-conversion-tool@ietf.org>; Thu, 23 Feb 2012 14:08:55 -0800 (PST)
Received: from localhost ([127.0.0.1]:34126 helo=vigonier.lan ident=henrik) by grenache.tools.ietf.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.77) (envelope-from <henrik@levkowetz.com>) id 1S0gps-0008Fw-SP; Thu, 23 Feb 2012 23:08:24 +0100
Message-ID: <4F46B8D8.5010307@levkowetz.com>
Date: Thu, 23 Feb 2012 23:08:24 +0100
From: Henrik Levkowetz <henrik@levkowetz.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Robert Sparks <rjsparks@nostrum.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> <4F45B07F.7080508@nostrum.com> <CANb2OvKJy=HT34KNFXFzN+3V6L33SgxUfxrrh_H2XufXPe6nXQ@mail.gmail.com> <4F465849.5020707@levkowetz.com> <CANb2OvJyzjgRyEt+2_cMz8nH=UfqjJ_f+2V87XYOCA8qtgPLvw@mail.gmail.com> <4F46A292.1080409@nostrum.com> <4F46A8BD.4020108@levkowetz.com> <4F46B577.8040502@nostrum.com>
In-Reply-To: <4F46B577.8040502@nostrum.com>
X-Enigmail-Version: 1.3.5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: rjsparks@nostrum.com, olau@iola.dk, housley@vigilsec.com, iola-conversion-tool@ietf.org, henrik-sent@levkowetz.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Cc: Ole Laursen <olau@iola.dk>, Russ Housley <housley@vigilsec.com>, 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 22:08:56 -0000

Hi Robert,

Inline:

On 2012-02-23 22:53 Robert Sparks said the following:
> Inline
> 
> On 2/23/12 2:59 PM, Henrik Levkowetz wrote:
>> Hi Robert, Ole,
>>
>> On 2012-02-23 21:33 Robert Sparks said the following:
>>>
>>> On 2/23/12 2:20 PM, Ole Laursen wrote:
>>>> 2012/2/23 Henrik Levkowetz<henrik@levkowetz.com>om>:
>>>>> Ok, so if this is used by the IESG or some ADs during the IESG processing,
>>>>> we should support it.  Do we have a straightforward way of associating a
>>>>> non-WG document with an area independently of who the sponsoring AD is?
>>>>>
>>>>> Since areas are groups, too, we should be able to have an association with
>>>>> the area in the same way that wg documents are associated with a WG, I think.
>>>> Yes. It sounds like we need to keep track of the area for a few
>>>> individually submitted documents here that conceptually belong to an
>>>> area, in the same way as WG drafts belong to a WG? Is that correct?
>>> I think this is mismodeling what we need a bit. Focusing on the
>>> individually submitted nature of the document may not be right. To
>>> put stress on it:
>>>
>>> How would you handle a document from a RAI working group that both
>>> Gonzalo and I needed to recuse on. Some other AD (let say Peter for
>>> this example) would be the sponsor. The doc should show from RAI and
>>> as a product of that RAI WG.
>> Agreed, but that's in line with what I (am trying to, at least!) propose
>> above.  See more below.
>>
>>> It seems natural to just have an area associated with a document at
>>> any time it is identified as IETF stream.
>> What I'm proposing is that this association can be either indirectly,
>> through an association with a WG, which would give the area of the WG;
>> or directly set to an area (which is independent of the area of any
>> sponsoring AD).
> 
> I'm OK with this proposal.
> Just to make sure I'm following the thinking -
> 
> If I had a Document, I could ask it for its area. If it was an 
> IETF-stream document, it would have something to say, either because 
> it could tell because what working group it came from, or someone 
> would have been required to tell it what its area was when it became 
> IETF stream. If it wasn't IETF stream, area would be None.

Ack.

> The only part that bothers me is knowing when to insist that someone
> provide the information, but that should be reasonably containable.

Agreed.

>>
>>>> If so, I suggest we just associate the document with the area instead
>>>> of the phony individual group and be done with it. I can add some UI
>>>> for that. Does that sound agreeable?
>>> Treating individual submissions as belonging to a psuedo-group has
>>> always disturbed me, but I don't know if that first proposal is the
>>> right fix.
>> The alternative is to not associate them with a group at all, until they
>> have been accepted by a WG, or a sponsoring AD.  I think that for the
>> purpose of code uniformity it's easier to associate them with a group
>> 'Individual Contributions' (or whatever) than to code the equivalent of
>>
>>    if doc.group == None:
>>       print "Individual"
>>    else:
>>       print doc.group
>>
>> everywhere we need to show something for such a document.
> Well, there's more to it than that or you would just bury that bit of 
> complexity in
> something like doc.displayDocumentSource()
> 
> But I have to apologize - I still have to be reminded that "Group"
> in the new schema is modeling something quite a bit more than an IETF
> working group.

Ah.  Right.  Ok.

> There are things like nomcoms, and external bodies, and a while bunch
> of other things that are Groups, so having a Group out there that is
> the container for IETF stream individual submission documents isn't
> bad. What I've cringed at is that someone might want to get/set the
> chairs of that group.

<<grin>>  Yes, we wouldn't want that.  It would be possible to enforce
limitations on that by using an extra table which gives permissible
role names for each group type; not really hard to do.  But we might
alternatively expect the Secretariat to not do silly things :-)


Best regards,

	Henrik