[Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer

[Chris Leonard]

On Tue, Aug 7, 2012 at 10:51 AM, Simon Schampijer <simon at schampijer.de> wrote:
> Hi,
>
> Something I wanted to propose in todays developer meeting (but as it did not
> happen), I send it here for an async proposal.
>
> We are short on maintainers and we have to grow new members that helps us
> share the load. The patch list is long and help in that regard will be
> appreciated that especially small patches do not take so long to get in.
>
> Lately Manuel Quiñones have been stepping up as a Sugar module maintainer.
> He is already maintaining sugar-artwork and sugar-toolkit-gtk3 [1]. He has
> been showing great talent with porting the Browse activity to WebkitGtk [2]
> and he has been working on porting the Sugar theme and the sugar-toolkit to
> GTK+ 3.
>
> We are currently working on the shell port to GTK+ 3 and introspection and
> Manuel has been advancing already quite a lot [3]. As all of those Sugar
> sub-modules are interlinked I think it makes absolute sense to add him as a
> maintainer to the Sugar shell as well.
>
> To make sure: the general work-flow should not change, patches have to be
> sent to the mailing list for review. For non-trivial reviews a maintainer
> should have at least one review, preferred a review and acknowledgment from
> another maintainer. It is good practice to leave a patch for a few days so
> everyone maintainer can at least have a high level look if he disagrees with
> an approach.
>
> I hope we can address the issues listed in that way,
>    Simon


What a great tragedy, we have contributions coming in faster than we
can approve them :-)

Here are my observations:

We have been blessed by a larger than usual number of contributors to
the core modules this cycle, just to mention a few of the new
contributors and apologies to anyone I've missed, dnarvaez, danielf,
Caspar and several others that are contributing via Activity Central.
As a community we want to encourage this influx by giving rapid
feedback (and ideally acceptance) of their contributions as a fitting
form of thanks for their efforts.

This will be an unusually "disruptive" development cycle because of
the underlying technology shift from gtk2 to gtk3, the removal of
obsoleted technologies like hippo, the introduction of introspection,
etc., etc., etc.  There is a large amount of ground to cover.

This cycle will see nearly every module touched and modified in some
fundamental way, which requires lots of coordination and careful
review of contributions against "the big picture".  Given the larger
number of contributors, having a larger number of "gatekeepers"
performing that detailed review and high-level integration is
essential to achieve the ambitious goals of this development cycle.

This cycle is seeing the proposed integration of a substantial series
of carefully considered feature enhancements coming from Activity
Central's Dextrose 3.  These features were all based on end-user
requests and all have been extensively field tested in deployments
running Dextrose.  Nonetheless, reviewing and accepting them is a
substantial task and again, it is only appropriate that Activity
Central's effort in developing these and offering them back to the
upstream should be recognized by a respectful consideration of their
contributions for inclusion.

Code shuffling:  Please forgive me if I mis-characterize anyone's
proposals, but I have seen ideas floated about rearranging functional
elements for a variety of reasons, whether it is abstracting
text-to-speech to a higher level or modularizing the control panel
functions to provide great flexibility for customization, there are a
number of ideas out there on moving bits of functionality about in the
code base in ways that clearly make sense to the proposer (and
probably many others) and are certainly worthy of consideration.

All of the above is more-or-less without really breaking any new
ground, but we also have the impending need to support touch input and
on screen keyboards being driven by OLPC's technology developments,
which will likely see the integration of new bits of code with
widespread potential impact.

There is a lot of work to be done and we need trusted hands guiding
that work into our repository and releases, I am entirely in favor of
granting manuq the privilege of tackling a portion of that important
effort in collaboration with silbe and erikos (doesn't dsd own an
OLPC-specific element of this as well?  I can't recall clearly.)
Manuel has my confidence that he will "do the right thing".

Given the scope of the effort being undertaken this development cycle,
it will be a minor miracle if we do not hit a "flag day" at some
point, but I am fairly confident that if we do, it will not be out of
sloppiness or inattention by the maintainers, but because of the leaps
forward being taken.  In the immortal words of Robert Browning "Ah,
but a man's reach should exceed his grasp -- or what's a heaven for?"

On a more somber note, the testing and QA phase at the end of this
development cycle will be all the more important because of what is
being attempted, I would like to ask all of the developers making
contributions to take that into account and make an equal commitment
to QA and testing towards the end of this cycle rather than furiously
coding a new feature up to the very last moment.

Warmest Regards,

cjl