Re: [Ayatana] Options, Configs and code paths

[Martin Owens <doctormo@xxxxxxxxx>]

On Wed, 2009-07-08 at 07:18 +0100, Mark Shuttleworth wrote:
> Elegance? No. Options? Perhaps.

Oh good, natural options and exceptional options are kind of different
beasts anyway, the first just come about by the way the code is built
and the second is the kind you have to add on later.

> Every code path needs tests. We have a relatively low level of quality
> in free software *because* we don't test our code. I know the ideology
> about many eyes etc, but the reality is somewhat different - there's a
> lot of crappy code on an Ubuntu CD.

Sounds like you need a bunch of packaging rules and scoring for test
code coverage, at least some automated tools for identifying issues.
Although the analysis of FOSS code I saw didn't show "relatively low
level of quality" as far as bugs per 1000 lines:

http://www.linuxtoday.com/developer/2006031800826OSCYDV

Do you have some data I have not seen for quality?

> In part, that's because there are so many unused code paths. That code
> rots, it lurks in the background, and it causes bugs and slows down
> development. Every time we have "some background option" added to
> appease someone, I worry that we're adding code which will slow down
> the primary thrust of development and fragment the testing we can do.

That's usually caused by half hearted implementation and poor code
flexibility to begin with. Not something that I've noticed in other FOSS
projects, depends on the feature, depends on the option, depends on how
easy the code can sustain the modification.

Brace code is to be avoided like the code rot it is of course.

> There's a perception that "alternative pathways" are free. They are
> not.

They're not free to maintain, but you can bargain the addition of
options in certain ways. For instance, if your background is going to be
loaded from an svg file anyway, then you might as well have the graphic
file setting as an option in the config. Even if not expressed in the
gui config.

Although I'd call that design flexibility since I like separating design
and function, gives the art types something to do without having to
bother programmers.

Alternatively if a programmer can implement the feature and satisfy code
coverage with tests then it's worth considering. Worse is when you get a
"Pidgin" problem, where core devs are arrogant and so indignant that
anyone could possibly have an alternative opinion that you end up
forcing a fork. Even though no one really wants to.

I've changed the thread title since it's something else now.

Best Regards, Martin Owens