[IAEP] SoaS as a Sugar Labs project.
tomeu at sugarlabs.org
Tue Aug 25 07:09:48 EDT 2009
On Tue, Aug 25, 2009 at 12:45, Martin Langhoff<martin.langhoff at gmail.com> wrote:
> On Tue, Aug 25, 2009 at 2:00 AM, David Farning<dfarning at 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
> 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.
> martin.langhoff at gmail.com
> martin at 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
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
More information about the IAEP