>> 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