>> There are many distributions that do not provide HAL, or >> worse on which HAL actually breaks basic functionality (i.e. >> keyboards/mice >> suddenly don't work, etc.). Sounds like we need to get R14.0 >> out the door ASAP, even if it it slightly buggy, so that we can start >> working >> on more fundamental problems. >> >> Thoughts are welcome! > > From where is this idea derived that we need to get R14 out the door ASAP? > Suddenly we have to push a "slightly" buggy release? Why? Who is keeping > score? > > My calendar says April, not May. > > Which fundamental problems? Like a few hundred bug reports? My concern is that we are in some kind of soft freeze until R14.0 is pushed out the door, meaning that it is difficult/impossible to remove reliance on deprecated (and in many cases flat-out broken) systems such as HAL. > How are we supposed to test this new hardware support when half of us > can't build a complete package set? That's a problem. All I am asking for is that those who can try it out so that obvious bugs can be squashed and so that I can start to get some idea of its reliability for potential inclusion in the next release. > Are we again pushing a buggy release? Seems we have seen that story, what? > twice now? > > Trinity is not "slightly" buggy. Trinity is buggy. Many bug reports need > resolution. Many build issues need attention. > > Trinity is broken with respect to building with gcc 4.7. > > If we spent time as a team addressing the bug tracker we could release a > non buggy R14. If we spent time as a team helping and coaching one another > we'd have fewer bugs. Almost every day David and I post build issues and > bugs. We receive no meaningful help. We resign ourselves to posting the > issues to the bug tracker and there the problems sit without resolution or > motion. > > We likely could resolve all build issues in less than a week if everybody > pitched in and helped. We likely could resolve dozens of bug reports if > everybody pitched in and helped. > > And then, maybe, we actually would have stable foundations on multiple > distros to thoroughly test the new hardware support system. I don't disagree with any particular point, but very few of us can dedicate that amount of solid time. HAL was becoming a nuisance for me along with the persistent lack of a viable replacement hardware library (which I really, really need to fix other problems such as the age-old numlock issue), so I wrote a 5000+ line replacement. That is not a small task, but it really needed to be done for long term stability and support. > Please don't rip HAL support. Not everybody is using bleeding edge distros > --- let people build whichever mechanism they want through build options. The only place HAL support has to be "ripped" is in kpowersave--I may end up renaming kpowersave to something else for the non-HAL variant, but needed to gauge the reaction here first. So, what should kpowersave be renamed to? "TDE Power Miser" is my current suggestion. :-) > Please don't push a buggy R14. I'll try not to, but the clock is ticking to some extent. For now let's aim for at least resolving all the build issues and user-visible bugs within 3 months. Build bugs are a real problem as two developers rarely have the exact same kernel/distro/hardware--this is why I have been unable to offer much help when build bugs do come up. For what it's worth I'm running a rebuild on Ubuntu/Debian now (thanks in part to the donations received during the spring fundraiser), so there is half a chance that a build bug or two might be resolved in the near future. Tim