[IAEP] SoaS as a Sugar Labs project.

[Tomeu Vizoso]

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