michael at laptop.org
Fri Apr 30 12:26:59 EDT 2010
> follows a plan about how to improve the situation regarding
> maintenance of our software modules. If you care about it, please
> reply even if only to say so...
> , or even better, comment on it and
> suggest improvements. I will assume that lack of replies mean people
> don't care about it and will stop caring about it myself.
> == The problem ==
> The process by which our software reaches to children is complex and
> involves several organizations. Sugar Labs is one of those and its
> responsibility is to provide the raw sources that organizations
> "downstream" such as OLPC, Fedora and Paraguay Educa will modify,
> package, ship and install. It's very important that modifications done
> downstream are kept to a minimum so that all downstreams share as much
> work as possible. This means that the raw sources we provide need to
> contain the features that downstream need in each release and that it
> contains as few bugs as possible.
One comment: for me, downstream modifications represent both essential sources
of knowledge about what actually matters and the emergence of new contributors.
Hopefully we agree that assisting and rewarding these tentative efforts (as
you, Daniel, and Bernie have done in your many visits to Uruguay, Nepal, and
Paraguay) helps us to gain contributors and to better understand what
> In order to provide good "raw sources", we have a series of processes
> that assure that the expected features are present and that the worst
> bugs are either fixed or at least well-known. These processes include
> testing, bug triage (keeping the bug database in order), source
> release, code review, user experience design and code development.
We disagree about the details of how these processes should be concretely
implemented but we substantially agree on the list of processes.
(That being said, I would probably add "evangelizing" and "experimentation" to
> An important role present in most of those processes is that of the
> module maintainer.
> A module maintainer takes responsibility for a part of the source
> code. The maintainer will release code at known times and will have
> worked so it has gone through the processes outlined above. Of course,
> the maintainer cannot do all the work by herself, but is ultimately
> responsible for it. Normally the maintainer will have spent most of
> her time triaging and fixing bugs, and will be trying hard to keep the
> module "in order" so that in future releases the maintenance burden
> doesn't grow too much as new code gets in. An important process in
> keeping the maintenance burden in check is "code review", by which the
> maintainer checks that the new code that gets in a release won't
> increase the maintenance burden too much.
I agree that responsible people are important but I don't really agree with
this characterization of how a responsible person does their work: I want my
maintainers to be spending most of their time merging patches, giving feedback,
or making awesome new contributions of their own.
(I also don't know precisely what you mean when you say "maintenance burden".
Could you please say a bit more?)
> The problem is that very few people in Sugar Labs are willing to do
> that maintenance work. We have people keen on packaging Sugar,
> deploying it, training teachers on it, developing new activities and
> new Sugar features, people write books about Sugar, setup help lines
> to support Sugar users, universities are given grants to study the use
> of Sugar, load machines with it, etc. Big amounts of volunteer time
> and money are being spent around Sugar but almost nothing is going to
> maintenance. Paradoxically, any use of Sugar requires that it is
> reasonably stable and most investments are made with the assumption
> that Sugar will keep being developed.
This mainly says to me that Sugar is at best partially ready for use.
It also says that people still feel an urgent need to change it a lot more
before they are sufficiently satisfied with it to commit to maintaining a
stable branch of it.
Why not just accept this and move on?
> I also want to make explicit that almost all maintenance effort has
> come from a few volunteers that are tired and disappointed about the
> little importance that has been given to this work. We are very close
> to have no maintainers at all in Sugar, meaning as well that nobody
> with the needed experience will be around to mentor new maintainers.
Again, this really says to me that people think that, today, Sugar most
desperately needs things other than maintenance.
Also, isn't experience maintaining other projects largely transferable to this
project? If so, I believe that new maintainers will appear when they are truly
Now, a quick comment on your plan: I still think that you're putting the cart
before the horse; namely, as I wrote in my most recent essay ,
> If, as Walter quips, we learn by doing and learn best when motivated
> by love (rather than duty) then it would behoove us to make Sugar
> development as lovable and active as we can.
Let's take, as a concrete example, the "patches in trac" vs. "patches by email"
debate which I've spoken to many of you about.
In the 9 days from April 11-20, there were 26 updates to bugs.sl.o by 15
alsroot bernie cjb cjl Clytie dfarning donghee dsd Niranjala80 pbrobinson
qazigzag quozl sascha_silbe satellit tonyforster uhu walter
In the 9 days from April 20-29, there were 46 updates to bugs.sl.o by 15 contributors :
alsroot bernie bert cjl FGrose ghunt jpichon kjorg50 mavrothal quozl
sascha_silbe sdz tonyforster uhu walter
The words "patch" and "review" do not really appear in these updates, at least
in the portion displayed by the Trac timeline.
However, this morning, I did a quick search for "[Sugar-devel] [PATCH]" and
pulled the mails from 9 days before April 20, which is when Bernie's mail about
handling patches by email went out, and from 9 days after.
In the 9 days before April 20, I count 1 subject line, 3 mails, and 2
contributors in 9 days:
Apr 13, Bert, Sascha (3)
Build squeakvm from tarball
In the 9 days after April 20, I count 14 subject lines, 90 mails, and 15
(Thanks, Raul, Bernie, James, Chris, Tomeu, Peter, Walter, Sascha, Daniel,
Andrés, Paul, Fred, Ben, and Jonas!)
Now, what hypotheses can we draw from these admittedly limited data?
I draw three tentative hypotheses:
1. Most current Sugar coders do, in fact, prefer contributing patches by
2. Patch contribution by email seems to result in both more contribution and
in more discussion than patch contribution by trac.
3. Making sugar's processes and commitments more lovable is the best
available way to succeed at our goals. (Including the goal of having
well-maintained stable branches.)
: Some authors names are hidden inside the threads themselves. The dates,
rough authors lists, and subject lines I counted are:
Apr 29, Raul .. Bernie, James (9)
_update_signal_match wasn't initialized
Apr 28, Chris .. Tomeu (15)
Remove the keep button from the default activity toolbar
Apr 27, James .. Peter, James (6)
disconnect on passphrase cancel #1805
Apr 26, Walter Bender
bundlebuilder should not use locale name
Apr 26, Bernie Innocenti
sl#1876: cleanup partially extracted bundle on filesystem error
Apr 26, James, Sascha, Daniel (6)
fix AP association failure after removing encryption #1674
Apr 26, Bernie .. Sascha (8)
Shave off unnecessary dependencies from jhbuild
Apr 26, Andrés, me, James (4)
#1725: Resize home window on screen size change
Apr 26, Sascha .. Paul, James (20)
use ConsoleKit instead of HAL for shutdown/reboot
Apr 25, Bernie, Sascha, Bert (6)
Move etoys to the extra-activities group
Apr 25, Michael .. Paul, Bernie (10)
use ConsoleKit instead of HAL for
Apr 22, James Cameron
Apr 22, James Cameron
passphrase dialog, remove destroy, fix duplicate error, catch...
Apr 21, James, Sascha (2)
improve encrypted wireless access point usability #1805 #1674
More information about the IAEP