From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-31-ewr.dyndns.com (mxout-079-ewr.mailhop.org [216.146.33.79]) by lists.bufferbloat.net (Postfix) with ESMTP id 1A9B82E041B for ; Thu, 24 Feb 2011 06:19:54 -0800 (PST) Received: from scan-31-ewr.mailhop.org (scan-31-ewr.local [10.0.141.237]) by mail-31-ewr.dyndns.com (Postfix) with ESMTP id 75A126F7D67 for ; Thu, 24 Feb 2011 14:19:44 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 76.96.30.24 Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mail-31-ewr.dyndns.com (Postfix) with ESMTP id 54E496FB2B2 for ; Thu, 24 Feb 2011 14:19:40 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta02.emeryville.ca.mail.comcast.net with comcast id BqBS1g0061Y3wxoA2qKfoh; Thu, 24 Feb 2011 14:19:39 +0000 Received: from [192.168.1.119] ([98.229.99.32]) by omta15.emeryville.ca.mail.comcast.net with comcast id BqKZ1g0020hvpMe8bqKdw1; Thu, 24 Feb 2011 14:19:38 +0000 Message-ID: <4D6668F4.5010705@freedesktop.org> Date: Thu, 24 Feb 2011 09:19:32 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: bloat-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Please enter issues into the issue tracker - Issue system organisation needed. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 14:19:55 -0000 We have lots of different issues to track. We are uncovering more and more with time, and the responsibility for the issues is all over the Internet ecology. These issues include drivers in multiple operating systems, queue disciplines, OS distribution problems, broken networks, broadband gear, ISP's with broken configurations, routers with broken configurations, etc, etc, etc. Many of the responsible organizations are completely unaware they have issues at the moment, and when they do wake up, the need to have a work list. Serious as bufferbloat is, and generating tremendous support costs as it does, it is hidden among most organisations issue tracking as obscure, hard to explain problems, that have heretofore defied analysis. I think both for the sanity of the upstream open source projects and companies that depend on it, commercial software and hardware vendors, and our own sanity, it's time to start to keep track of these problems. A simple example is in the following mail, where Juliusz identified a bunch of Linux drivers with problems communicating back-pressure. https://lists.bufferbloat.net/pipermail/bloat/2011-February/000036.html These driver bugs, of course, can and will be worked upstream in the project and/or responsible organisation; but from a practical point of view, these issues aren't really going to be fixed until people can actually take action on their own (by upgrading affected OS's, routers, broadband gear, etc. as appropriate). So I think we need to track bufferbloat issues in possibly a different way (and maybe with a bit different work flow) than a usual tracking system. First ===== I think we need to capture what we know. I encourage people to start entering issues in the bloat tracker found at: http://www.bufferbloat.net/projects/bloat/issues/new Note that redmine lets us move issues from one (sub)project to another, so we're best off capturing what we know immediately; we can sort and redeal later. Note: "We're all bozos on this glass bus, no stones allowed". We know there are problems all over; issue descriptions should always be polite and constructive, please! Noting these issues will help people already involved (the mailing list had > 120 people the last I looked, from large numbers of organisations) take concrete action. Issues buried in mail threads are too easy to lose. Second ====== As this effort grows, we'll need to organise the result, and delegate it appropriately as the effort scales. Today, we're probably best off with a single project: but we hope certainly that won't be reasonable with time, possibly almost immediately. We installed Redmine in particular as it has a competent issue tracking system, as well as good (sub)project management, which can easily be delegated to others (one of the huge problems with Bugzilla or Trac is the lack of project management). If anyone is looking for a way to help bufferbloat and has experience with tracking systems on large, complex projects, I'd love to see someone organise this effort, and put some thought and structure into the categories, (sub)projects and work flow of issue states. I know from my OLPC experience just how important this can be, though this is a somewhat different situation. Best regards, - Jim