On Tue, Aug 25, 2009 at 2:00 AM, David Farning<dfarn...@sugarlabs.org> wrote: > This is the goal. But as Martin correctly points out, policies and > rules come at a non-zero price, thus we must be careful that the > benefits outweigh the costs.
Thanks! Best summary of what I wanted to say :-) Some additional notes that may be of use. (My excuse? Code is compiling on the other window.) Thinking back on how large projects handle "subprojects" and "component" splits... there are clearly 2 ways of splitting things 1 - By 'architectural' and technical divisions -- the way you guys have sucrose, lactose and various pepsins :-) 2 - By responsibility, and here I mean "we consider it important enough that we'll get it done, regardless of where it is in the stack". Many projects have a "core" and "contrib" split showing exactly this distinction. It is useful to be aware of the two approaches, and to use them where appropriate. Internally and technically #1 matters. User-facing #1 is endlessly confusing and IMHO #2 makes more sense. When, as a developer, you have 3 bugtrackers to look into for the _same_ bug in the same code (or in the interaction of 2 tightly coupled components) you are in a situation where #1 is being used, and does not help. At least as a developer you know the (architectura, social, political) reasons behind the proliferation of bugtrackers. Alas, only your most involved end users will know how to navigate them. (Small example: Right now, just one simple dev task we're coordinating with Hamilton involves 2 bugtrackers. With SoaS "moving out", it'll involve 3 if we "do things properly". Not the end of the world, and yet...) IMHO, having things neatly laid out for developers is not that important. We know that SoaS is actually a custom Fedora, and that Browse.xo is "not Sugar". From a user's PoV, bugs in SoaS and Browse.xo are "Sugar doesn't work". Of course, we'll educate the involved users so we can debug the problem with them. But a well defined point of entry for all things Sugar (docs, bugs, etc) is a major win -- if they knew all about your components and which one is causing the problem, they'd probably have a patch too :-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep