From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 5211220097C for ; Sun, 4 Dec 2011 13:27:03 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id pB4LR0U3009219; Sun, 4 Dec 2011 13:27:00 -0800 Date: Sun, 4 Dec 2011 13:27:00 -0800 (PST) From: david@lang.hm X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Where we're winning X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2011 21:27:03 -0000 On Sun, 4 Dec 2011, Dave Taht wrote: > All: > > I am incredibly open to suggestions as to how to make cerowrt less > of a success disaster. I think one key thing to do is to step back and think about what the definition of 'stable' vs 'rc' mean the purpose of cerowrt is to put new stuff out for people to experiment with. by defintition, this means that you don't know for sure what the results of things will be, so by the time you figure it out to create a 'stable' release, the result is not going to be anything that you care about because it is now standard. I think you need to accept that there is going to be some amount of experimental stuff that may break. I think the key requirement is that it needs to be easy to turn off the experimental stuff to go back to the default upstream behavior if it doesn't work for someone. At that point, it should not be a -rc release as it's ready for people to really use. there appear to be three parts to cerowrt. 1. picking useful tools from openwrt to include by default 2. modifying specific packages to introduce new features. 3. modify default values I'm wondering if the right thing to do isn't to stop trying to ship a complete firmware, but instead ship packages to be put on a standard openwrt distro. thinking about this. I see the value breaking down along the following lines 1. picking useful tools to include by default I don't see a lot of value in shipping a distro to do this. have a page somewhere listing the packages (possibly even with cut-n-past installation lines) 2. modifying specific packages with the exception of the kernel (which needs to be device specific), you should be able to make modified versions of any packages to be downloaded and installed very muchlike #1 for the kernel, I don't know what it takes with openwrt to install a new kernel (is it a complete reinstall of everything? or is there a way to have two kernels and switch between them?) 3. modifying config options can this be done either through cut-n-past instructions or via a package to install? with the extent of these changes, people would need to install the squashfs version instead of the jff2 version. by doing these things as modifications/instructions rather than a packaged distro release, you don't lock yourself down to a single hardware platform. It will require more knowledge on the part of the people using it, but I don't think that the people without this knowledge will be willing to run -rc versions. This would also make it easier to answer questions like I asked a couple weeks ago about what parts are ready for production use and what are really experimental. thoughts? David Lang