[IAEP] maintenance

[Michael Stone]

Tomeu,

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

I care.

> , 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
downstreams need?

> 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
the list.)

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


-----

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 [1], 

>   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
contributors [3]:

   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 [4]:

   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
contributors [4].

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

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

Regards,

Michael

[1]: http://dev.laptop.org/~mstone/draft-sugar-core-priorities-01.txt

[2]: http://bugs.sugarlabs.org/timeline?from=04/20/10&daysback=9&ticket=on&milestone=on&wiki=on&update=Update

[3]: http://bugs.sugarlabs.org/timeline?from=04/29/10&daysback=9&ticket=on&milestone=on&wiki=on&update=Update

[4]: 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  
add model.network.find_connection_by_path

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