From owner-freebsd-current@FreeBSD.ORG Tue Jan 13 06:54:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 181CA16A4CE for ; Tue, 13 Jan 2004 06:54:55 -0800 (PST) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AC8D43D48 for ; Tue, 13 Jan 2004 06:54:54 -0800 (PST) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 772D41469F; Tue, 13 Jan 2004 08:54:53 -0600 (CST) Date: Tue, 13 Jan 2004 08:54:53 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: Matteo Riondato In-Reply-To: <1074003293.18384.62.camel@kaiser.sig11.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Tue, 13 Jan 2004 08:56:29 -0800 cc: freebsd-current@freebsd.org Subject: Re: Status reports - why not regularly? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2004 14:54:55 -0000 > That's quite a problem, because how can we inform normal users about new > features that will be included, if developers don't tell "anyobody" they > are working on those features? Well, you can't; but, if you go down this direction, you'll never even get started on writing a report. It's impossible for the reports to be complete and comprehensive. What they ought to do is start out by being quick and very, very, regular. Once that happens more developers are likely to start sending in information. The error in the previous attempt may have been "we'll hold publication until we hear back from project x, y, and z". It should be the other way around -- if x, y, and z want to get their information out there, the burden should be on them. Also, the previous attempt tried to include a paragraph about every project every month. If there's no report, there's no reason to try to spend time trying to make the developers submit one, and then trying to edit that up for consistency with the others. All just IMHO: quick and often are going to trump slow and methodical. mcl