On Tue, 2004-07-20 at 14:09, Peter Soetens wrote: > On Friday 16 July 2004 13:56, Philippe Gerum wrote: > > On Wed, 2004-07-14 at 10:00, Peter Soetens wrote: > > > Hi guys, > > > > > > Thanks again to the Milano team for a great meeting. We had lenghty > > > discussions which made me forget part of my agenda : I'd like a RTAI > > > 3.0r5 bugfix release because of some critical fixes in the lxrt-posix > > > implementation. Since we use this layer in Orocos, our users need it > > > desperately... Maybe other developers found bugs also after r4 ? > > > > FYI, we are preparing 3.1-test4 concentrating on a few bugs affecting > > the LXRT support, but not only. It seems that we have converged enough > > to be able to release the last -test release for 3.1 in a short time > > from now (less than a week). Once -test4 is out, 3.0r5 will follow > > shortly, backporting critical fixes for LXRT we've added lately to 3.1 > > (not in the CVS yet). > > Ok. But... :-) I'm not sure if postponing rX releases until 'enough' bugs are > fixed, is desired. I'm more in favour of a monthly or so release if any bugs > got fixed in the meantime. You'll need another release after the last one > until you tell you users that version is no longer supported (or RTAI becomes > bug free :-] ) >
In a perfect world with many committed contributors, all you've said so far is very sound; however, having a regular release pace like I tried to implement for more than a year now costs a *lot* of time, because each release must take care of limiting if not preventing regressions, with many compilers and lots of distros that happen to use the latest Linux support (e.g. NPTL) we had problem with until recently. This issue is especially demanding in the RT/embedded world where people are even more conservative than in many other fields, so you cannot simply afford to push half tested releases, otherwise they would just give up using them. There is a balance to find, and for the time being, I am the one to blame for the longer release cycle that took place a few weeks ago: I want LXRT to _stabilize_ NOW, and for this, we need to concentrate on fixing the bugs we know of. This work is about to end, since four major bugs have been found during the last two weeks that should dramatically improve LXRT's MTBF, btw. This said, the fact that I'm currently the branch maintainer for 3.0, 3.1, fusion and Adeos mostly in my spare time is not a reasonable situation. What would be really helpful is that someone officially takes the burden of maintaining 3.0 with the required level of commitment (it's about 2 days/month for 3.0 now). This person could then team up with Paolo around 3.1r2 or 3.1r3, so that less things are left in my hands, which is not a sound situation in any case. > Peter > > > > > > cheers, > > > Peter -- Philippe.
