sascha-ml-ui-sugar-iaep at silbe.org
Fri Apr 30 18:31:41 EDT 2010
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
==== 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
==== 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
==== 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
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
8 Tomeu Vizoso (6 release, 1 maintenance, 1 workaround)
9 Sascha Silbe (4 bug fixes, 3 improvements, 1 cleanup, 1
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)
29 bug fix
3 style fix
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 490 bytes
Desc: Digital signature
Url : http://lists.sugarlabs.org/archive/iaep/attachments/20100501/89c68317/attachment.pgp
More information about the IAEP