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/
signature.asc
Description: Digital signature
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
