trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: April 2012

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

From: "Timothy Pearson" <kb9vqf@...>
Date: Mon, 16 Apr 2012 15:11:04 -0500
> On 04/15/2012 07:22 PM, Timothy Pearson wrote:
> 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!
>>
>> Tim
>
> OK, 'tempered..'
>
>    NO, NO, NO, NO! I know I always come back to this, but it is always
> better to
> "get it right" even if it takes a bit longer, than to "get it out the
> door" and
> then pay the price of increased bug reports and support issues that can be
> completely avoided by simply taking a bit more time to begin with.
>
>   I would propose that R14 NOT be release until:
>
> (1) libpng15 issues are fixed (digikam, etc..); and
> (2) it builds without '-fpermissive' on gcc47
>
>   Otherwise, we are releasing an R14 with no digikam, etc.. due to
> libpng15 and
> code that cannot be built on systems with the current gcc without fudging
> it.
> Also, there hasn't been confirmation that tde continues to operate
> normally with
> the dependencies built on gcc47.
>
>   I would rather see a tde 3.5.13-3 than a 3.5.14-1. It just make sense to
> me to
> have the next release be solid and build on the current gcc. I don't think
> we
> will see another gcc upheaval for some time. With many distros moving to
> gcc47,
> I think we iron those issues out before release.
>
>   That's just my cut on it. Spend a little more up-front, save a
> whole-lot-more
> on the backside...

OK, will do!  You and Darrell have convinced me that this is the correct
course of action.

I would ask this: Please make an Etherpad of prioritized non-build bug
numbers so that we all know which bugs should be dealt with first.  Seeing
build bugs constantly crop up on this list doesn't help me, as TDE builds
just fine here and I would like to start fixing bugs that are not
build-related.

As an aside, including a replication procedure in each bug report really,
really helps a developer pick it up to start repairing it.  I know Darrell
does a good job of this, but perhaps other members of the team could do
some triage and append a bug replication process to bug reports that do
not currently contain one?

Thanks!

Tim