On 04/16/2012 12:55 AM, Darrell Anderson wrote: >> 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 > I missed this discussion mostly, but here are my thoughts. Why not provide also a HAL based kpowersave just for R14, alongside with the new improved one that Tim wrote? This is a phasing out period. After R15, we drop it entirely. That gives everyone a heck of a lot of time to work out their issues. I like the release mantra "make each release suck less" and that's what I think our goal needs to be. We can't ship a perfect release, but we can improve from every prior release. it may not seem like it, but many a bug has been sqaushed since November 1st. I don't have a great gauge on this, but 187 bugs have been modified, and are resolved since 3.5.13. barring any bugs that were modified, reopened or anything else, 187ish bugs have been resolved. I think this is tremendous progress. 29 bug reports sit with "Patch Avail" which I think should be all considered release blocking in a sense. We have those patches available, we should get them out in the wild by the next release. Just some thoughts, Calvin PS. why not just call it TPowerManager? It's not really for "saving" like kpowersave, because my intent could well be to run my system at a maximum rate, what it's job is to manage the power related aspects of the system.