On Wed, Feb 1, 2012 at 3:32 AM, Robert Collins <robe...@robertcollins.net> wrote: > Hi, please glance at > https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts > > The basic idea is that we are where we are today because we didn't at > any point put a cap on the overheads involved in maintaining > Launchpad. The ratio of developer time that goes into maintenance vs > delivering new functionality is quite high, and if it continues to > grow we may never climb out of the technical-debt hole that we have. >
I very strongly agree with the general principle, heartily endorse the item you added to the ReadyToCode wiki page and think the policy is heading in the right direction. The policy document as written wouldn't help me think about the ongoing maintenance cost of a proposed change. The list of "What things increase cost" is a true one, but sometimes requires knowledge of the future. A simple rule would be nice, but you're right that it would be hard to come up with one. As Martin says, examples could help. Another thing could be rephrasing the items as thought-provoking questions: Does it add extra steps to an existing process? Does it add code? You could also do what Drizzle did and make a rule that we all know is arbitrary and not entirely correct but is certainly easy to follow. This would be a fitting break from the Launchpad (as-a-product) tradition of covering every imaginable use case. Another idea would be to make the policy even stronger. Say that from now patches must reduce maintenance cost, and specify what that might mean: make LP faster, make dev cycle faster, remove code, remove the need for documentation, increase architectural transparency etc. Still another idea would be to compel everyone to watch Rich Hickey's excellent talk that Gary shared months ago[1], and replace the entire policy with "make things simpler". On another note, now that I'm not working on the Launchpad team, it's even more obvious to me that you guys are tackling some really interesting and deep problems and making some really good progress. There's a lot that you could teach other teams in Canonical and the world in general. If you don't get around to pimping yourselves more, I'm going to start stealing your ideas and make myself look heaps smarter than I actually am. jml [1] http://www.infoq.com/presentations/Simple-Made-Easy _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
