[IAEP] maintenance

[Tomeu Vizoso]

On Fri, Apr 30, 2010 at 18:26, Michael Stone <michael at laptop.org> wrote:
> 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?

Sure, even more, I think instead of talking about us and them they
should be represented in our community in a way proportional to their
importance (much more than now). That's the point of the deployment
team.

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

Yes, I think I haven't explained myself very well above. What I was
trying to say is that the person that is going to be deciding what is
ready to go in or not needs to know very well what it takes to
stabilize a code base. AFAICS, this means having done the work herself
of bug triaging and fixing. But I think we agree that maintainers will
be delegating very often in order to get things done and also to get
more people in the loop.

> (I also don't know precisely what you mean when you say "maintenance
> burden".
> Could you please say a bit more?)

I was referring to the amount of effort needed to stabilize a code
base after a change.

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

That's not what I have heard from our downstreams. They want to move
their work upstream but we haven't found a way yet. People working
together in the community and deployment team can discuss that way.

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

See above.

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

Sure, but I see very very improbable that the deployers in Uruguay,
Paraguay and Peru are going to hire experienced FOSS developers. Would
love to be wrong, but I'm afraid we cannot hope for that.

Of course, if our community decides that the maintenance issue doesn't
need to be tackled urgently, our current maintainers can move on to
other stuff and at a later point SLs can try getting the machinery up
again. I would strongly advise against it because I know how much it
took us to reach here, but it's not my decision.

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

Lately I'm finding myself repeating several times per day that I'm in
favour of reviewing patches in the mailing list, and I really cannot
understand why people keep trying to discuss it. Has anybody ever
heard anybody saying that reviews in trac are better?

Can we agree that we all would prefer to have reviews in the ml and
move on to how to make that happen? But please, do so in the other
thread that we are having on code reviews.

Regards,

Tomeu

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