Jim, Your comments are very accurate and this is exactly our idea as well for the firmware development process. And that's why we are having Cozybit post *partly* tested firmware drops on the TechWiki. This is usually tested by our QA team but on a shorter QA cycle and that too in parallel to the testing efforts going on in the developer community. On the other track, we are posting a more solidly tested firmware drop on the Marvell website.
If you haven't yet noticed, the firmware versions posted on these two places are also different - the ones that are posted on the TechWiki are of the type 5.220.xx.yy and those on the Marvell website are of the type 5.110.xx.yy. So, there already exist two tracks right now just the way you mentioned. Whenever a firmware version is released to OLPC from either one of the two branches, the changes are merged to the other branch also so that they are in sync. Coming back to the point of including of which wireless firmware in the build of laptops scheduled by OLPC, which one to use would just be a recommendation from us. The final decision would be yours based on the amount of testing done by the community at large and comfort level within the community. Thanks Ronak -----Original Message----- From: Jim Gettys [mailto:[EMAIL PROTECTED] Sent: Monday, March 05, 2007 6:35 PM To: Ronak Chokshi Cc: Marcelo Tosatti; David Woodhouse; [email protected]; sugar Subject: RE: last day for another stable build Ronak, "Bugs are good" - Doug Clark I'd like to encourage a bit different view of the situation, and that the what your propose below become the norm, rather than the exception. Rather than there being one set of firmware which has seen a full QA cycle as the "norm", I urge that there also be an experimental version of firmware also available that has not necessarily completed the full formal QA cycle. Here's my reasoning: Formal QA testing has some *really* good characteristics: it is much more likely to uncover certain classes of bugs (e.g. memory leaks that occur over time, as an explicit test that is left running for days can uncover such bugs better than the much more random testing done by developers or experimenters). It's also good at preventing previously seen bugs from reappearing (regression testing), and scaling may also be systematically tested. But it is very much less effective at uncovering new bugs: formal testing is always done the same way, and only after you've released such QA'ed software would you even start using the firmware in other environments and circumstances not expected by the formal QA process that might discov new bugs. If all firmware goes through an extended QA cycle before it sees the light of day, then you have in effect serialized the discovery of new bugs that formal QA can not find, as you will generally not have the right hardware/software to trigger the bugs in your test environment, until *after* you've seen the bug, reproduced it, and added explicit tests to your test environment. A good example of this was recently provided by the problems associating with the WRT54GL access points; until this problem was noted, the process to isolate the bug, and then add the hardware to a QA testing environment doesn't even begin. If all testing in the field is left until after an extended formal QA cycle, then those discoveries and fixes will not start for an extended period; putting both a QA'ed and an experimental set of firmware in parallel will speed the process of bug discovery and bug killing. Certainly, when we get to the BTest-3 and CTest builds, and for FRS for sure, we'll likely want to choose to use a set of firmware that has completed a full QA cycle; but I believe we should be planning on a two track development path on the firmware, to speed the bug discovery process as much as possible. Best regards, - Jim Gettys . On Mon, 2007-03-05 at 17:04 -0800, Ronak Chokshi wrote: > Marcelo, > > We feel that whenever OLPC schedules a build of laptops, the wireless > firmware to be used in them should be the last stable version which > has been released through Marvell website and has most of the bug > fixes from the Marvell engineering team as well as the required > feature set targeted for that build of laptops. Also, more > importantly, we would also like to make sure that the wireless > firmware has passed most of the tests done by the Marvell QA team. All > this takes time and in this build's case, since the multicast support > is required and has been very newly added, there was not enough time > to rigorously test the development firmware released on the TechWiki > by Cozybit or even time to merge the recent bug fixes to this version > of the firmware. Hence, I said that "for the purpose of this build, we > will have to use the development build released by Cozybit on the > TechWiki". So, I would look at this more as an exception than a > regular behavior that we would like to follow going forward. > > > > Thanks > > Ronak > > > > -----Original Message----- > From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] > Sent: Monday, March 05, 2007 4:47 PM > To: Ronak Chokshi > Cc: Marcelo Tosatti; Christopher Blizzard; sugar; [email protected]; > David Woodhouse > Subject: Re: last day for another stable build > > > > Ronak, > > > > On Fri, Mar 02, 2007 at 02:21:25PM -0800, Ronak Chokshi wrote: > > > Hi Marcelo, > > > For the purpose of the build, we will have to use the development > build > > > released by Cozybit on the TechWiki > > > (http://laptop.org/teamwiki/index.php/Image:Libertas-firmware.tgz) > since > > > as highlighted in the Release Notes of these release, Cozybit is > still > > > to adopt our bug fixes. > > > > > > We are testing this build (v5.220.9.p10) in our lab over a network > of > > > approx. 15 days. We will be doing this through the weekend and will > post > > > our test result details by end of the day on Monday. This will give > > > everyone confidence in the firmware build that will go in the next > build > > > of laptops. > > > > I just noticed that v5.220.9.p10 has been released. > > > > What is not clear to me is whether we can include such release in our > OS > > build or not? > > > > It appears that we can, given your comment above saying "For the > purpose > > of the build, we will have to use the development build released by > > Cozybit on the TechWiki". Is that right? > > > > Thanks > > > > > > > > Thanks > > > Ronak > > > > > > -----Original Message----- > > > From: Marcelo Tosatti [mailto:[EMAIL PROTECTED] > > > Sent: Friday, March 02, 2007 10:30 AM > > > To: Ronak Chokshi > > > Cc: Marcelo Tosatti; Christopher Blizzard; sugar; [email protected]; > > > David Woodhouse > > > Subject: Re: last day for another stable build > > > > > > On Fri, Mar 02, 2007 at 10:01:13AM -0800, Ronak Chokshi wrote: > > > > Hi Marcelo, > > > > I would suggest to include the firmware v5.110.12.p0. This is the > most > > > > stable build. Every other build on the TechWiki is a development > build > > > > and work in progress. > > > > > > > > Whoever will include this build, here are the instructions on > getting > > > > the binary from our website: > > > > > > > > - Go to http://www.marvell.com/drivers/search.do > > > > - Type "OLPC" in the Product category and hit Submit. > > > > - The first version in the search results that pops up should be > > > > v5.110.12.p0 and should say " USB 8388 OLPC Firmware for MPP (Mesh > > > > Portal Point)" > > > > > > > > This has a zip file and a .bin in it. This is the firmware build > that > > > > you would need. > > > > > > Ronak, > > > > > > We need multicast support. What is the plan regarding a Marvell > release > > > of such feature? > > > _______________________________________________ > Devel mailing list > [email protected] > http://mailman.laptop.org/mailman/listinfo/devel -- Jim Gettys One Laptop Per Child _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
