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?