trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

Re: [trinity-devel] kpowersave now working without HAL

From: Darrell Anderson <humanreadable@...>
Date: Sun, 15 Apr 2012 21:55:31 -0700 (PDT)
> 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.

Fair enough. I'll post my list of build and usability issues. I'm sure others can do likewise. From that effort we'll know what is ailing us the most.

I suspect a significant number of build issues can be resolved in ten minutes --- if only an experienced person would look at the report.

David and I have shown that we can apply patches and rebuild just about as fast as anybody. All we need is help --- guidance --- and the bug reports will disappear like the dew on a hot sunny morning.

A 3 month plan is fine and doable. I always have preferred the "we release when ready" motto. If we adopt a fixed release date then quality assurance suffers. Always.

I'm aware of the demands on people's time. I have them too.

I'm now building for two different Slackware releases. I plan to expand that to three and add the respective 64 bit versions. That provides us more coverage and exposure to potential breakage.

I don't underestimate the HAL issue and appreciate the effort. As long as HAL remains a part of the basic build options then I am content. The upcoming release of Slackware has moved away from HAL but 13.1 will not and 13.1 remains in use. We need to build for both.

Let Calvin rename kpowersave.

Darrell