[IAEP] SoaS as a Sugar Labs project.

[Martin Langhoff]

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
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.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