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