unity-design team mailing list archive

[Jim Rorie <jfrorie@xxxxxxxxx>]

Cody, this is an excellent post.  

It's the best explanation of the project's reasoning, without the hard
edge.  You will still get push back, but now you have a concise,
coherent argument that isn't quite so authoritarian. This really needs
to go in a FAQ.


Jim



On Wed, 2009-10-21 at 13:36 -0500, Cody Russell wrote: 
> 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
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature