[websec] proposed workflow for trac issue tickets (HSTS)
=JeffH <Jeff.Hodges@KingsMountain.com> Sat, 28 January 2012 01:38 UTC
Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7195421F85D5 for <websec@ietfa.amsl.com>; Fri, 27 Jan 2012 17:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.206
X-Spam-Level:
X-Spam-Status: No, score=-100.206 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 RFrmPkLor+2g for <websec@ietfa.amsl.com>; Fri, 27 Jan 2012 17:38:08 -0800 (PST)
Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id CF86A21F85D4 for <websec@ietf.org>; Fri, 27 Jan 2012 17:38:08 -0800 (PST)
Received: (qmail 29008 invoked by uid 0); 28 Jan 2012 01:38:08 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 28 Jan 2012 01:38:08 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=KgSORQSUUP9XQfM/61SyXg835A8x2ara9miHJFbLze0=; b=1abkdyOXh6Frscg115vbggV0yqetpxdIws6WM3uIUUTtAs9V/Cip62xcFn015nT4mXtpf2ve/kO4xfByAaLox6GtTwyrwuVhf4pjwmylpeN1T4PLx0bmjsagtsoOHgwO;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.138]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1RqxF2-0000li-2y for websec@ietf.org; Fri, 27 Jan 2012 18:38:08 -0700
Message-ID: <4F235180.2030302@KingsMountain.com>
Date: Fri, 27 Jan 2012 17:38:08 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [websec] proposed workflow for trac issue tickets (HSTS)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Jan 2012 01:38:09 -0000
I did some modest checking around, and there is not a ietf-wide process for using the issue tracker aka trac. Each working group is up to their own devices whether they wish to use it, and if they do, for establishing their workflow for such use. trac is installed with a nominal default workflow, and we apparently can't customize things like new additional values for "Status" or state transitions on our own. The default as-installed workflow is illustrated here.. http://trac.tools.ietf.org/wg/websec/trac/wiki/TracWorkflow I /think/ we're using trac >= version 0.11, so the second diagram should apply. I've submitted all the issue tickets for strict-transport-sec with default attribute values (e.g., for status), and it appears no one else has edited the attrs, so the status of all the tickets is "new". for a nominal websec wg workflow for specification bugs, without "reassignment" of tickets, I suggest.. 1. ticket initially submitted, status: "new" 2. ticket addressed in a spec revision, status <- "closed", resolution <- "fixed" 3. folks review the spec a. no objections to ticket's fix, then goto 4. b. if wg consensus (as assessed by co-chairs) is that the ticket's fix needs revision, ticket is "reopened", goto 2. 4. ticket closed, really. So, if there aren't any objections to this workflow, I'll close all the strict-transport-sec as resolution <- "fixed". If issues arise with any of the ticket's fixes in reviewing the spec, we can selectively reopen. If new issues arise, then we submit new ticket(s). =JeffH