[Sugar-devel] Maintenance, reviews, QA & co

[Sascha Silbe]

Simon Schampijer <simon at schampijer.de> writes:

>> VI.  Accept patches into mainline that are likely to increase the number
>>       of contributors using Sugar themselves (A) or to increase their
>>       usage of Sugar, even if the patch doesn't directly benefit the XO
>>       target user base. It should not have a negative impact on the XO
>>       target user base, of course. This addresses goals 2, 3, 4 and 5.
>
> When we setup SugarLabs the goal was to make Sugar available on other 
> platforms like the XO. This goal is still the case.

I'm talking about the target audience, not the hardware platform. The
question is whether to accept patches that most school children [1]
neither have a use for (i.e. no direct positive impact on them) nor get
in their way (i.e. no negative impact either).


>> VII. Work on making Sugar more modular, using upstream components and
>>       standard protocols or APIs as much as possible (L), allowing users
>>       to mix and match components or simply configure them differently
>>       (A) and reducing the footprint of bugs. This addresses goals 2, 3,
>>       4 and 5.
>
> Using standards and upstream components has been a goal as well. So we 
> just have to continue that road.

So I can push the window manager related fixes [2,3] I posted last year?


>> The two major changes are making in-depth reviews by senior developers
>> optional and non-blocking (II.)
>
> But require public short reviews by some senior developer, correct?

Yes, that's III.


>> as well as accepting "no ceiling" (VI.) and standards compliance
>> (VII.) patches.
>
> But modularity comes at a cost. This should be decided on a case per 
> case basis.

Not being modular usually comes at an even higher cost in the long
run. Changes affect a larger part of functionality, requiring more
extensive testing and increasing the baseline of user-visible bugs. It
also reduces flexibility, preventing the user from choosing different
components that better fit their need. Right now, Sugar is essentially
all-or-nothing. You either use Sugar, or you can choose between and mix
a wide variety of other components. You can either launch Sugar (and
quit Gnome) or launch Gnome (and quit Sugar), not mix them to have the
best of both worlds.

Similarly, not being standards compliant will come back to bite you
sooner or later. It may work with the exact versions you tested with,
but any update of software we rely on can suddenly break the system in
unexpected ways. It also increases the costs of switching components,
like the matchbox to metacity change that created a lot of fallout.

Sascha

[1] http://wiki.laptop.org/go/Our_market#Child_is_a_nebulous_term.3B_what_is_the_exact_age_range_you_are_targeting.3F
[2] https://patchwork.sugarlabs.org/patch/826/
[3] https://patchwork.sugarlabs.org/patch/827/
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20120821/eaf75e41/attachment.pgp>