[IAEP] maintenance

Tomeu Vizoso tomeu at tomeuvizoso.net
Tue May 4 12:47:26 EDT 2010


[Sorry for the late reply, I didn't received this email from
sascha-ml-ui-sugar-iaep at silbe.org but I did receive messages from
other of your addresses]

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

I'm sorry if I sounded like asking anybody to give more of their time.
I'm frustrated by not having a community and a deployment team but
that's not the fault of any individual. I think the need for these
teams is big and I'm just giving it visibility. Sorry if I sounded
differently.

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

I agree in general lines, but would like to remark that in order to
grow in developers we also need to grow in other directions than just
accepting more code. I think that we need to have communication
channels with those using Sugar and also need to give some thinking to
the community aspects.

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

Agreed, I feel I need help as a maintainer to welcome new contributors
and I have tried to start discussions about it without much success in
the past. This could have been related to my lack of time to keep
pushing the subject, thus my proposal of having a community team.

> == 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":

Somewhat agreed, but note that maybe the actual problem is not
maintainers not being able to maintain their single module, but rather
each of them having to maintain several modules alone, do the testing,
ask for people to test, debug downstreams, talk to deployers, relay
emails from mailing lists (and sometimes having to translate them),
answer doubts of all kinds in irc and the ml, manage the release, etc,
etc.

So maybe it's not the role of maintainer that is superdimensioned, but
that our community is not using efficiently its resources.

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

Agreed.

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

I'm very sorry to hear you feel like this, I assure you it was not my
intention. Note that I said "very few people in Sugar Labs are
willing" which shouldn't equal to "Nobody is doing maintenance". I'm
very aware that you have step up to maintain sugar-jhbuild and I have
personally reviewed lots of your patches. But I think that Sugar needs
that _many_ more people do the same, thus the "very few".

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

Ok, but we still need help with triaging, welcoming newcomers, design
feedback, testers, release managers, documentation, new tools,
reaching our users, etc, etc. And also we need that important issues
are left undiscussed because everybody is too swamped. That's the
point I was trying to make.

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

Sorry, hope you don't feel it has been a waste of time.

Regards,

Tomeu

> 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


More information about the IAEP mailing list