[Sugar-devel] Bug tracking Vs Patch review

[Tomeu Vizoso]

On Mon, Aug 30, 2010 at 19:31, Bernie Innocenti <bernie at codewiz.org> wrote:
> El Mon, 30-08-2010 a las 14:44 +0200, Tomeu Vizoso escribió:
>
>> Went through http://wiki.sugarlabs.org/go/0.88/Platform_Components and
>> googled for how each project prefer patches to be submitted:
>>[...]
>
> I probably contribute to very different type of projects, all of which
> use lists for reviews: aros, autotools, binutils, cairo, coreboot, gcc,
> git, glibc, gnash, linux, mesa, openwrt, xorg, uclinux, util-linux-ng.
> Sorry for not providing links to the individual instruction pages -- I
> double-checked the cases where I was unsure.
>
> Perhaps low-level people like myself have different levels of tolerance
> for overhead? But anyway, not long ago it seemed that, also among the
> Sugar developers, there was a good level of consensus on moving towards
> a lightweight process based on email... or at least allow both
> submission methods, on the submitter's discretion.

Yes, we agreed on that, but then, just for the sake of argument,
several unchecked statements were made that unfairly represented the
current Sugar development model and the work of several members of our
community.

It left me again in the uncomfortable position of having to choose
between going back to work and leave those false or misleading
statements uncontested, and spending my time googling and writing
unpleasant replies.

We have only a few paint buckets available and maybe none of them are
our favorite colors, but endlessly discussing about the best color and
trying to blame others for not having more paint buckets is not going
to get the shed painted.

>> Didn't knew we had a design process, do you have a link?
>
> We don't have a formalized process, nevertheless UI patches require a
> prior discussion on the mailing-list with the Design Team, and often
> need to be accompanied mock-ups describing the design. Making these
> requires all the UI code to be already written, unless you're really
> good at painting.

Welcome to community-developed FOSS: you need to effectively
communicate with your coleagues as well as write good code.

In case it needs to be said, I'm extremely grateful at Christian,
Gary, Eben, Eduardo and the others that put their experience, effort
and time thinking about our UI, discussing it with others, drawing
mockups for other people's features, etc

> I have seen a number of otherwise good patches being rejected because
> they had not gone through this (undocumented) process.

Unfortunately, I have seen people spend months coding a feature and
not having found 30 seconds to write a heads-up email to the list
asking for user experience feedback. At some point I took a minute to
write such emails for 3 other people's features. Obviously it helps if
you start the discussion just before you start coding, and not just
after.

>>  Anyway, most
>> patches don't affect UI. For the ones that do, isn't it fair that the
>> people involved in UI are given a chance to give their opinion? Same
>> with giving a chance to deployers to give their opinions.
>
> All opinions are good and welcome, but when one needs 4 different
> opinions to converge before changing a line of code, the process gets
> engulfed.
>
> Sometimes UI designers come up with an idea that nobody would implement.
> In other cases, programmers come up with UI changes that designers
> reject. When you get both, the work needs to go through maintainer
> approval of each affected module.

Again, you are misrepresenting me just for the sake of argument,
there's a wide chasm between giving others the chance to opine and
taking those opinions seriously, and having to reach unanimity on a
perfectly defined design.

> Add to this that many maintainers are unresponsive or vacant.
>
> Very few patches make it to the end of this funnel. All the others
> result in lost effort and frustrated contributors. We've seen some of
> them complain, the majority simply disappears.

And we are going to fix this by throwing shit to our colleagues.

>> > review process
>> > (one per affected module).
>>
>> See links above, seems to me that code review is an accepted practice
>> in FOSS. Any reason we should be special?
>
> Having some form of reviews is great, but we broke up Sugar in tightly
> coupled modules, so that any non-trivial change often spans across 2 or
> 3. Typically it's sugar + sugar-toolkit + sugar-artwork.

One person is working on merging them, several others have preferred
just to complain about it.

> Different people may be competent on different parts of the code, but
> I'd rather have one incompetent decision maker rather than many
> conflicting ones.

That's not true, and actually, may be interesting for you to try to
find out why our maintainers don't waste their time arguing with each
other and seem to have an easy time finding agreement.

>> > As a result, lot of good patches have got
>> > stuck along the way, bitrotting in trac for 6 to 9 months.
>>
>> Given what I wrote above, do you think it could be worthy considering
>> other factors for this?
>
> Sure, there might be multiple negative factors working at the same time.
> Overhead of our workflow is just the most visible one.

Visible because someone has invested a lot of time giving it
visibility in the mailing list and made bombastic statements so other
people were forcedly dragged into the discussion?

> Another one that concerns me very much that filing patches in the bug
> trackers replaces the "many eyes" that should characterize FLOSS
> development with just one pair of eyes... or even no eyes at all.
>
> Very few people look daily at activity in the bug tracker and even fewer
> participate in discussions of tickets filed by others. As a result, we
> often learn about a patch only when (and if) it lands in git... when
> it's too late for a public review.

You are again mixing unrelated things just for the sake of argument.
We could have very well patches tracked in trac with the queue exposed
in the mailing list and with reviews happening in the mailing list. We
don't have this setup because someone needs to invest time on setting
it up.

>> I don't find it more boring than the other projects I contribute to,
>> but I have to recognize that the split between maintainers and
>> contributors we have in Sugar drains my energy considerably, specially
>> when excessive rhetoric is used to make points.
>
> After a good night of sleep, I realize that my post sound too much like
> a rant and too little like a constructive proposal. I apologize about
> that.

And this email I'm replying to is constructive in which way?

>> In any case, I'm sure we can make contributing much more welcoming and
>> exciting, I'll like to hear proposals, but sadly they are likely to
>> involve work and then someone needs to do it.
>
> My proposal does not come in the form of yet another process because
> what I'm suggesting is actually deregulation: move from a rule-based
> system to case-by-case judgment by one maintainer who cares for the
> entire codebase.

Contributors are the first ones that benefit from having a clear
submission process. They can check if they are being treated fairly
and can influence the way their work is accepted. You weren't around
when Sugar moved from an ad-hoc patch acceptance to have a process but
that doesn't mean that we have to start again just so you can better
understand why.

> You say that there are not enough people to cover all the roles defined
> by our processes, but the more people you add, the more development will
> get engulfed.

Again misrepresenting what I have ever said, we only have two roles
and we have more than two people. We need more people doing more work
but I don't see what it has to do with our processes.

> Believe me on this: wherever I go, I meet plenty of people who say that
> Sugar Labs is too hard to work with. Even people who are generally more
> tolerant than me with rigid processes.

Contributing to FOSS is hard for me as well, during the past years I
have become part of several other communities, earning the status of
committer and maintainer in some, sending patches, discussing
processes, speaking at conferences, creating new modules,
participating in hackfests, etc. It has been really hard at times to
adapt to the different ways of working and it's still frustrating at
times.

I think despite the hard moments I have been successful at that and if
I had to make a recommendation it would be to not whine, do good work
and to try harder to understand the others. Once you have gotten
respect because of your work *and* you have gotten a fair
understanding of what's going on, then you will be in a good position
to propose improvements.

>> We have bugs that get fixed even before a build has carried it, and we
>> have bugs that are there since nearly day zero. How is that news? Try
>> browsing through the bug trackers linked above and you will find the
>> same.
>
> The bad news is that we often introduce serious bugs that would be
> easily spotted by a glance at the patch

What do you mean, that nobody glanced at it?

> and yet they manage to get
> through all our complicated processes.

Stop repeating that, I have shown you how most FOSS projects just
below Sugar have similar and often more complicated submittal
processes.

> One example. For the last 2 weeks, code in jhbuild has been crashing on
> startup for several people (anish, tch, myself) on several distros
> (Fedora 13, Fedora 14, Ubuntu Karmic).

Patches were promptly made available in the mailing list and some have
already been accepted by Sascha into jhbuild.

> Regardless, we proceeded to
> release 0.89.5 tarballs that downstreams promptly turned into broken
> packages (tested on Fedora).

You clearly had different results than me when testing on F14, have
you filed bugs or reported them in some place?

By the way, this is called integration testing and it happens every
cycle in GNOME's jhbuild and again when stuff gets packaged at first
in Fedora.

> Why would something like  happen in the face of all the steps we take to
> ensure quality? This episode alone proves that no amount of rules and
> processes can ever replace the minimum amount of coordination and
> testing required to ensure that the software we ship does at least
> start.

The problems found during the integration phase are due to the
unexpected effects of putting together for the first time specific
versions of hundreds of different dependencies built with specific
sets of build options (such as the gnome-keyring issue with
mission-control). How did you expected to catch those by reading Sugar
patches?

> We seem to be missing the equivalent of a "product manager"... someone
> who cares for the product as a whole. In a different occasion, Walter
> noted the need for an "architect", but in a project like ours these are
> very much the same thing, just with an emphasis on the present or on the
> future.

It would help if you described that role in some details, otherwise
can mean too many different things.

> In the Linux world, this is called a Linus. Not even 100 module
> maintainers will ever fulfill this one vital role.
>
>
>> Maybe you have been right since day zero of this discussion and we
>> need to adopt the same processes the kernel has, but in any case
>> changes are most probably going to require that someone does some work
>> and we seem to have some difficulty there.
>
> We merged a total of 355 patches in sugar over the last 365 months.
> Exactly one patch per day. Over the same period, Linus merged 100 times
> this number of patches,

Looks like you are onto something big here. After you fix Sugar you
can go fix GNOME and the rest of FOSS projects, then with 100 times
more productivity Microsoft, Apple and Google will disappear in a puff
of smoke.

> meaning that maintaining Sugar should be
> feasible even as a part-time job.

And we have how many full-time maintainers?

Regards,

Tomeu

> --
>   // Bernie Innocenti - http://codewiz.org/
>  \X/  Sugar Labs       - http://sugarlabs.org/
>
>