16 Apr
2012
16 Apr
'12
12:18 a.m.
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? 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