[Cerowrt-devel] no 3.3.8-4 yet

[Cerowrt-devel] no 3.3.8-4 yet

[Dave Taht]

I'd hoped to get a cleaned up version of 3.3.8-3 this weekend but ran
into multiple snags.

+ package signing landed thx to the ever prolific steven walker
+ progress was made regarding the last showstopping bug in
quagga-babel (ipv4/interface updates)
+ progress also in quagga for authenticated routing info (denis is
doing great stuff)
+ I fixed the debloat script to lower the packet limit in fq_codel and
also compensate for the ethtool
   syntax change. Same fixes for simple_qos
+ Made transmission do CS1 on ipv6 and ipv4
+ Put out an RFC patch to the codel list to handle ECN differently
that I expect to cause controversy.

- Although I pushed out a bunch of stuff to openwrt, most of it didn't
actually land yet there
- The openwrt buildbot cluster(s) went into chaos again - major fixes
went into place but more
   build servers are still needed
- I didn't figure out how to actually sign packages
- I noticed that GRO (generic recieve offload) is now on in linux 3.3
and I'm very adverse to all methods
  of bulk shipping packets around (like tso/gso especially). I don't
quite understand the effects of GRO
  yet...
- hope the quagga patches land soon
- need to fix qos-scripts along the lines of simple_qos
- still run out of memory fairly easily under some stressful benchmarks
- didn't get to the upnp problem

My personal life, finances, emotions in general are very chaotic at
the moment so it's difficult
for me to commit to dates and schedules for cerowrt. Spending 3 weeks
away from the continuous integration
process with openwrt cost me a week's worth of effort just to catch
up. Openwrt is attempting a freeze itself
so I'm doing my best to get stuff tested that needs to make it there...

And cerowrt, bufferbloat, codel, etc are all unfunded projects -
despite trying to get them funded for 16 months - so I have some paid
stuff coming up I'll need to focus on outside of these projects very
soon just to keep my own lights on.

So I'm in a bit of a quandary re how to make the best progress forward
at this point. I'm not going to have
a lot of spare time this week, for sure, to focus on this, as badly as
I would like to have a good stable release
to base a ton of testing and benchmarks on, and for you all to play with.

I'm delighted that we have so many volunteers from so many walks of
life and companies participating
in all the efforts we have going. I'm glad that I worked full time on
this stuff for this long and that all the results - especially for
codel and derivatives are ever more promising -  but...

I will certainly argue that my own focuses on research and on the
original planned feature set for cerowrt is a real problem - package
signing is a major feature we've wanted to have in the original
product definition and I'm delighted to be able to test it - and the
quagga work has been going on since last august and is looking great -
and fiddling with torrent over this weekend exposed three issues with
fq_codel that need to be addressed -

but I'm not scaling, and I'd like to find ways to scale this up better
than it currently is.

I am thinking that the best thing to do would be for me to step down
as project maintainer, and
see if someone else could step up to stablize cero enough to be
deployable as a base for all the
other research projects we have. And/or focus on the funding problem
really hard -

or, merely apologize for the upcoming slowness in release cycles and
keep at it at a reduced level.

Certainly it will be easier to freeze cero after openwrt freezes.

Regardless I do hope to get 3.3.8-4 out by the end of the week, with
sources, and then I'm going
to have to stop for a while, again. but that's it. hope.

-- 
Dave Täht
SKYPE: davetaht
http://ronsravings.blogspot.com/

Re: [Cerowrt-devel] no 3.3.8-4 yet

[Dave Taht]

One thing that might work better from my perspective is breaking
things into a string of "dev" releases and then trying to do CI on
them more automatedly without any testing by me.

...except when I break the package db with the new opkg support, and
the fw rules aren't forwarding right right now

I really hate to waste other people's time with stuff that is entirely
untested however. My overall policy has been to integrate the release,
adding new features, bug fixes, etc, then testing for at least 24
hours on several routers including my main one, then do an
announcement that it was "safe" to try it, with what the new features
are. Lately people have been beating me to the announcements...

That said, cutting that cycle down would speed matters up and reduce
my workload.  I feel that if I establish a clear "dev" vs "somewhat
safe for real use" set of builds things would go faster for everyone,
and those that really want to be on the utterly bleeding edge can be.

Does that work?


> --
> Dave Täht
> SKYPE: davetaht
> http://ronsravings.blogspot.com/



-- 
Dave Täht
SKYPE: davetaht
http://ronsravings.blogspot.com/

Re: [Cerowrt-devel] no 3.3.8-4 yet

[Maciej Soltysiak]

[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]

Hi Dave,

About crystalizing dev builds. I think we could have a small set of
conditions for clear "dev" builds, say:
"at least 4 out of 5 dedicated testers reporting they could run it for at
least 48 hours without crashes, unplanned reboots or unexpected network
behaviour".

You could setup a recurring meeting in our calendars to put in place
something like this:
a) you build on every 4th thursday
b) testers fetch/install next friday
c) testers run it for the weekend
d) testers report on Monday
e) dave decides wheter to make it a solid dev build or not.

I can be a tester, I've been using various builds for some time now, they
really work for me.

One positive comment on functionality:

I no longer have to IPTABLES -I FORWARD -j ACCEPT to allow my wired TV to
discover my wireless media server client and DLNA works OK. (I know, it's a
lazy/insecure way of fixing it)
All the best!
Maciej

On Mon, Jun 18, 2012 at 6:52 PM, Dave Taht <dave.taht@gmail.com> wrote:

> One thing that might work better from my perspective is breaking
> things into a string of "dev" releases and then trying to do CI on
> them more automatedly without any testing by me.
>
> ...except when I break the package db with the new opkg support, and
> the fw rules aren't forwarding right right now
>
> I really hate to waste other people's time with stuff that is entirely
> untested however. My overall policy has been to integrate the release,
> adding new features, bug fixes, etc, then testing for at least 24
> hours on several routers including my main one, then do an
> announcement that it was "safe" to try it, with what the new features
> are. Lately people have been beating me to the announcements...
>
> That said, cutting that cycle down would speed matters up and reduce
> my workload.  I feel that if I establish a clear "dev" vs "somewhat
> safe for real use" set of builds things would go faster for everyone,
> and those that really want to be on the utterly bleeding edge can be.
>
> Does that work?
>
>
> > --
> > Dave Täht
> > SKYPE: davetaht
> > http://ronsravings.blogspot.com/
>
>
>
> --
> Dave Täht
> SKYPE: davetaht
> http://ronsravings.blogspot.com/
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

[-- Attachment #2: Type: text/html, Size: 3310 bytes --]