[IAEP] maintenance

[Sascha Silbe]

On Fri, Apr 30, 2010 at 12:38:14PM +0200, Tomeu Vizoso wrote:

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

First of all: I care deeply about Sugar (Labs). If I don't reply to your 
mails, especially ones as important as these, it's not done on purpose. 
I'm hitting my personal limits. My time is split up between study, work 
for hire (to pay the rent), Sugar, XO-1[.5] work, family, a few minor 
projects and sometimes even some leisure time. My workflows also didn't 
(and still don't) scale well to the diverse amount of work I'm doing 
these days (e.g. fixing a bug that affects Sugar often involves at least 
non-SL upstream and one or several distributions).
The replies I've read so far - from Michael, Christoph, Martin, Bert and 
Walter - all made rather good points that I don't have much to add to. I 
will, however, try to explain my views on the future of Sugar Labs.


IMO what Sugar Labs needs most in the near future is developers. For 
activities as well, but even more so for the core.
We not only need to find new contributors and welcome them, but also try 
to make the best of what (or who, to be more specific) we currently 
have. We need to cope with the fact that most of us are not paid to do 
the work, so a) have limited time and b) need to be kept motivated. We 
need to make development fun, not frustrating.


== Welcoming new contributors ==

Contributors start out small. They write a patch to fix a bug, or add a 
small feature. Over the time, after becoming familiar with Sugar 
internals and the other people working on it, they might step up to do 
regular maintenance tasks. But remember they always start small - if we 
don't manage to make new contributors comfortable, we won't get anyone 
to maintain anything (unless paid for).
An important part of making them feel comfortable is making it easy for 
them to involved as well giving fast, positive, helpful feedback and 
merging finished patches soon.


== Coping with what/who we have ==

As I mentioned above, most of us work on Sugar in their spare time (or a 
limited part of their work time). My guess is that this is exactly the 
reason there are so few people willing to do the job "maintainer" as 
it's currently defined for Sugar. It's a lot of work and requires 
_continuous_ dedication of time to the task.
What we need is to make the job description fit the people we have, not 
find people who fit the description. We need to split up the work of 
"the maintainer":


==== Bug fixing ====

As shown below this is already spread out. We don't need to require the 
maintainer to do it (of course (s)he is more than welcome to!).


==== Reviewing ====

Apparently only due to misunderstandings, this has been done only by the 
maintainers in the past. Nevertheless I think the new process of 
allowing anyone (as opposed to just "module peers") to do reviews is 
much better. There are a lot more people that can provide insightful 
hints for any single patch than there are approved "module peers".

While we might still require "the maintainer" to acknowledge (as opposed 
to review and test) patches, I quite agree with bernie this needs to 
happen in a timely manner. Letting patches gather dust for several weeks 
discourages contributors.


==== Non-release tasks like adding new languages ====

Are reasonably low effort that the maintainer can do it. Some of it 
might even happen via the code review process in the future, if it's 
streamlined enough.


==== Releasing ====

This is a genuine maintainer job. Since we do time-based releases, this 
requires the maintainer to spend some effort at specific times. 
Fortunately it shouldn't take too much time in total.



== Sidenote: Nobody is doing maintenance ==

> The problem is that very few people in Sugar Labs are willing to do 
> that maintenance work.

You keep repeating this. Personally, I find it insulting. Most of my 
time is spent on debugging and incremental improvements on existing 
features. Judging from the commit logs it's similar for all other 
committers. Counting commits for the last 6 months (first commit 
2009-11-06, latest commit 2010-03-28) of the "sugar" repo (master 
branch):


           17 Simon Schampijer (7 release, 4 bug fix, 1 improvement, 1 
style fix, 1 revert, 3 maintenance)
           18 Pootle daemon (18 translation)
           14 Daniel Drake (9 bug fix, 2 improvement, 1 
reintroduce-feature, 1 cleanup, 1 revert)
           11 Aleksey Lim (6 bug fix, 3 improvement, 1 style fix, 1 
cleanup)
            8 Tomeu Vizoso (6 release, 1 maintenance, 1 workaround)
            9 Sascha Silbe (4 bug fixes, 3 improvements, 1 cleanup, 1 
refactoring)
            2 Sayamindu Dasgupta (1 bug fix, 1 improvement)
            2 latu (1 improvement, 1 style fix)
            2 Martin Abente (relayed by Simon) (2 bug fixes)
            1 Bernie Innocenti (relayed by Simon) (1 improvement)
            1 Eben (relayed by Simon) (1 improvement)
            1 Daniel Castelo (relayed by Simon) (1 improvement)
            1 tch (relayed by Tomeu) (1 Feature)
            1 rgs (relayed by Simon) (1 bug fix)
            1 Yuan Chao (1 translation)
            1 Paul Fox (1 improvement)
            1 Kenny Meyer (1 bug fix)
            1 James Cameron (1 bug fix)

Summary:
29 bug fix
19 translation
15 improvement
13 release
       4 maintenance
       3 style fix
       3 cleanup
       2 reverts
       1 reintroduce-feature
       1 workaround
       1 refactoring
       1 Feature


Sorting commits into the categories I chose is often subjective, but the 
end result is clear: most of the work goes into improving existing 
functionality, not new features (even if you filter out the improvements 
to the one newly-added feature).



PS: It took me about half a day to write this email. That's one of the 
reasons I haven't replied to your earlier ones yet: it got pushed out 
again and again because I expected it to take a lot of time.

CU Sascha

-- 
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: 490 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/iaep/attachments/20100501/89c68317/attachment.pgp