[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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