Backtracing, Invalidated Bugs and Quality

[Null Ack]

2008/8/21 Markus Hitter <mah at jump-ing.de>:
>
> Am 20.08.2008 um 11:42 schrieb Null Ack:
>
>> I'm not convinced that the strategy of asking users to install
>> specialised debugging packages is the right way to go. I see a very
>> low hit rate with this working in practice.
>
> How about getting this even more automated? Apport would have three buttons:
>
>  [ Abort ]       [ Submit Report only ]  [ Allow getting bug fixed ]
>
> The third button would not only send the bug report, but replace (apt-get)
> the standard package with a symbol-equipped equivalent as well. Having a
> debug version of a package among standard packages hurts only neglible and
> most users won't even notice.
>
> Voi-la, next crash time Apport will come along with a backtrace.
>
Markus I particularly like your suggestion here. If there are certain
types of bugs that cannot be fixed without backtraces of debugging
symbols we must come up with easy tools on the desktop that creates
those conditions.


>
>> 1. The Debug By Default Build.
>
> Good idea, but the distro won't fit on the CD any longer. Don't know if this
> is an issue for developers.
>

Personally I dont care about the size, I'd just burn a DVD.


@Bryce - I dont think it matters what other processes other projects
use. To my way of thinking it is about process improvement and having
processes that are all geared to delivering the outcomes. Outcomes
that show Ubuntu to have rock solid stability, to be easy to use, to
have a quality user experience and so on.

@Emmet - I think it's unhealthy to treat the difficulty/time in fixing
bugs to the developer as the criteria for what gets look at. A quality
user experience should be the primary factor and any developer in my
book who's committed to Ubuntu quality would be tenacious about
chasing it.

Back to Markus:

>
>> 4. Extending The Ubuntu Entry Criteria.
>
> This would hobble invention of new packages immediately. As seen with the
> recent Empathy discussion, new packages don't go straight from the
> developer's alpha release into the distribution CD anyways.
>

I'm not so sure it would hobble open source software projects. Can I
please explain more fully? I am talking about packages that the Ubuntu
architects have all ready allowed into the distro. In this case for
example, we might be considering allowing in a new revision of gedit
into the alpha repos. I'm not talking about new packages all together.

Best practices on commercial projects that I've seen would involve
something along the lines of:

* Devs come up with the new code
* It is fully code reviewed by a human and made to meet certain benchmarks
* Static testing on the code occurs using static testing tools and
made to meet certain benchmarks
* and so on

In the case of the Ubuntu with our example new version of gedit:

* Has any code review been done?
* Has any static testing tool looked at the code?

As to the implementation, as I said it would have to be carefully
implemented. Can I summarise please:

Core basis for my extending the entry criteria argument: The earlier
problems are fixed, the less compounding multiplier effect of time and
money goes into fixing it.

I'm suggesting a staggered implementation. There are many ways this
could be done, one might be:

1. The Ubuntu security team start a pro active security initiative
that uses a static test tool to identify problems with memory
management that are security problems. The security team contact the
upstream projects with saying something along the lines of "were using
this code analysis tool and we suggest your code has security
problems".

2. Case studies and outcomes are shared on the websphere. Promotion of
the benefits occur over time and open source interest rises.

3. Ubuntu makes the leading step in showing their commitment to
quality by requiring that all upstream projects run the security test
static test tool before it will be accepted into the repos. Tools are
bit to make this pretty easy for upstream.

4. As time goes on, this becomes second nature. More people get
interested in it and adds on are written that expand what the static
test tool looks at and expands the rules regarding acceptance of new
code from existing repo packages.

Skip to Step 22: Imagine my ultimate vision where every upstream
project is required and does perform extensive static testing on their
code and there is pages of standards about criteria for Ubuntu entry.
Imagine a teenager with a killer idea for a really cool app, and he
comes along to IRC and says "Oh, what the heck, why do I have to deal
with this crap?" And the cowboy developer is responded too by a
seasoned open source dev guru who replies "because it results in
better code, with better quality, with better user experiences without
encumbering you with doing it all yourself".