Ubuntu-qa Digest, Vol 18, Issue 7

Dennis Limwanya infodelim at yahoo.com
Mon Mar 16 08:21:32 UTC 2009



Dennis Limwanya Jr.  
P.o Box 31546, Lusaka-Zambia. 
Tel: +26 211 212703 Email: infodelim at yahoo.com 

......Seek not to change the world, but choose to change your mind about the world. What you see reflects your thinking. And your thinking reflects your choice of what you want to see.

--- On Fri, 3/13/09, ubuntu-qa-request at lists.ubuntu.com <ubuntu-qa-request at lists.ubuntu.com> wrote:


From: ubuntu-qa-request at lists.ubuntu.com <ubuntu-qa-request at lists.ubuntu.com>
Subject: Ubuntu-qa Digest, Vol 18, Issue 7
To: ubuntu-qa at lists.ubuntu.com
Date: Friday, March 13, 2009, 8:00 AM


Send Ubuntu-qa mailing list submissions to
    ubuntu-qa at lists.ubuntu.com

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa
or, via email, send a message with subject or body 'help' to
    ubuntu-qa-request at lists.ubuntu.com

You can reach the person managing the list at
    ubuntu-qa-owner at lists.ubuntu.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ubuntu-qa digest..."


Today's Topics:

   1. Re: Exit Criteria to Production and Release Blocker
      Nominations (Null Ack)


----------------------------------------------------------------------

Message: 1
Date: Fri, 13 Mar 2009 01:51:58 +1100
From: Null Ack <nullack at gmail.com>
Subject: Re: Exit Criteria to Production and Release Blocker
    Nominations
To: Scott Kitterman <ubuntu at kitterman.com>
Cc: ubuntu-qa at lists.ubuntu.com
Message-ID:
    <40ef7d130903120751y779f9edbk228d325690626551 at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hi Scott,

2009/3/12 Scott Kitterman <ubuntu at kitterman.com>:

>
> If you set the bar to high, we'd never release.

Countless software projects do it all the time as a matter of routine.

>
> Adding a flag does nothing for getting more fixing done.
>

Frankly that claim is needlessly dismissive of the proposal and
reflects your general resistance rather than a practical objection.
The process I'm suggesting is to minimise the impact of special case
quality bugs that would otherwise go unresolved for an extended amount
of time. I have already suggested that Canonical might consider their
paid dev resources for these special case bugs as a way of getting
traction on issues that otherwise are not in the long term interests
of Ubuntu.

Again, its routine for organisations both free and commercial to set
policy and process, and to actually follow it.

>
> Right. ?Since the bulk of our archive is automatically sync'ed from Debian this is another massive piece of work that there is no one to do.
>
> Unless you can find more developers, then your proposals need to reduce existing workload if you want new work done.
>

I'm not convinced there is no one to do it. Critics of Ubuntu have
been vocal on the claim that Ubuntu contributes relatively little in
terms of core upstream projects in comparison to the number of commits
by companies such as Red Hat, Novell, Intel and so forth. Thats not my
argument, my main argument with mandatory static analysis of code is
that upstream would face the work, who are already doing development
on their code. The work would largely not be a distribution issue.

Sure, the more cowboy type devs who consider themselves hacker types
who can do anything they want would object, but the reality is the
FOSS ecosystem already has a bunch of rules in place. Rules to do with
packaging, coding standards and so forth. A number of times I've seen
SVN accounts revoked for breaches of rules from FOSS projects. Another
example is the routine of patches being rejected by a FOSS project for
breaches of rules. I'm talking about a vision in which static analysis
of code becomes another standard part of those rules.

I have a fair bit of experience with different tools and I consider
coverity prevent the best there is when it comes to C, C++, C# and
Java. The US Government and the company have provided a free facility
for upstream automated code review. So far some FOSS projects have
done heaps of work on fixing the issues it finds (it has in my
experience the lowest false positive detect rate), some a little,
others none.

In my proposal I discussed the idea for partnering with the other big
distros, Fedora, OpenSuse, Debian and so on to implement the same
change program along with GNU and the FSF. A change program that could
be *implemented gradually* over time, so that the ecosystem has time
to adjust to it. Besides, with the big distros behind it, it just adds
weight to the change becoming a mandatory rule for FOSS projects.

Its in everyones best interest to fix bugs at the earliest lifecycle
point and static analysis of code is one of the key steps to realising
that objective. Besides the security bugs its famous for identifying,
it has a good habit of picking up bugs that are tricky to identify in
runtime testing but are griefers once you get into production with the
userbase.

Nullack



------------------------------

-- 
Ubuntu-qa mailing list
Ubuntu-qa at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa


End of Ubuntu-qa Digest, Vol 18, Issue 7
****************************************



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20090316/3ec19c15/attachment.html>


More information about the Ubuntu-qa mailing list