On Tue, Aug 25, 2009 at 12:45, Martin Langhoff<[email protected]> wrote: > On Tue, Aug 25, 2009 at 2:00 AM, David Farning<[email protected]> 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 :-)
Users would enter any bugs they find in only one bugtracker, the one setup for the distro they are using: SoaS, Fedora, Ubuntu, etc. Developers would submit patches to the bug tracker of the module, if someone puts the energy required to debug and write a good patch, I think finding the right bugtracker won't be a problem for that person. If someone feels very strongly about having downstream bugs in the same bug tracker as upstream sugar, then that person is welcome to create a bug triaging team and keep the bugs triaged. Regards, Tomeu > cheers, > > > > m > -- > [email protected] > [email protected] -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
