[Cerowrt-devel] Where we're winning

[david at lang.hm]

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