Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

[Cody Russell <crussell@xxxxxxxxxxxxx>]

On Wed, 2009-10-21 at 13:29 -0400, Jim Rorie wrote:
> I'm not talking about visible checkboxes or customization
> applications.
> Don't go the KDE route.  Give power users/admins access to gconf for a
> few variables that could have a big impact on user experience.

As a developer on the DX team doing some of the new desktop stuff, I
can't help but cringe a little when I read things like this.  There's
more to worry about than simply cluttering or uncluttering the UIs with
checkboxes.  When Mark talks about things like having opinionated
designs and stuff, I think I read that a little differently than some
people here do.  I read it as well-defined code paths and workflows that
will lead to faster and more stable software.

It's really easy to say "I want a boolean gconf value to do X, I don't
care if there is no UI for it and it won't be part of the default
install so what harm can come of it?"

Canonical is trying to make an effort at doing more thorough automated
testing of software we create.  These type of hidden options may seem
trivial, but they're almost certainly going to do two things: 1/ they'll
be a maintenance burden and 2/ either seriously complicate the automated
testing or they're going to be ignored by the testing software.  I have
a feeling they're going to be largely ignored, because we are already on
very tight schedules and we're obviously going to be focusing testing on
the default UI/workflow/setup that is in the specifications.  If people
start throwing all kinds of random gconf options into the code to do
things that aren't in the design vision, I doubt Mark or the design team
want us spending time expanding unit and functional tests to handle all
those cases.

So we skip it and hope for the best.  Then eventually bug reports start
coming in where the app is misbehaving here or there, but it's not
misbehaving in our tests.  Who's going to be responsible for fixing
those bugs?  I know from past experience in upstream projects that it's
easy for someone to contribute something and then disappear, and it's
left for the maintainers to deal with fallout.  This is what I mean by a
maintenance burden.

So the end of the story is that the developers fall behind schedule,
can't deliver everything that's asked of them or can't deliver it to the
level of quality that we're trying to, and then the entire platform is
not advancing as quickly as it could and should.  This sounds like I'm
exaggerating probably, but I really don't think I am.  When a single bug
is filed against an Ayatana app that's not reproducible on a standard
install, and is caused by some corner case from a gconf key getting set
in a way that is unspecified then a DX team member switches contexts to
spend a couple hours debugging it.  That's a couple hours spent on
something that affects almost nobody, and a couple hours LOST on work
that could be spent on something that will affect almost everybody.

/ Cody