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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
