2008/8/21 Markus Hitter <[EMAIL PROTECTED]>: > > 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". -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
