[Cerowrt-devel] Where we're winning
david at lang.hm
david at lang.hm
Sun Dec 4 13:27:00 PST 2011
On Sun, 4 Dec 2011, Dave Taht wrote:
> 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
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
thinking about this. I see the value breaking down along the following
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
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
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
More information about the Cerowrt-devel