[Sugar-devel] Bug tracking Vs Patch review

[Tomeu Vizoso]

On Sun, Aug 29, 2010 at 21:01, Bernie Innocenti <bernie at codewiz.org> wrote:
> (I had overlooked this message)
>
>
> El Sun, 01-08-2010 a las 16:47 +0200, Tomeu Vizoso escribió:
>> - several (most?) FOSS projects track patches in a bug tracker and
>> seem to thrive in contributions. Maybe they are wrong and we are
>> smarter, but we shouldn't assume they are all stupid.
>
> I thought it was a tiny minority, actually... A complicated review
> workflow is a common "best practice" in Java/RUP shops. The only
> high-profile OSS project that was using a bug tracker for reviews was
> Xorg, but they switched away from it because it was not working very
> well (I know this because I interviewed several Xorg hackers on
> #xorg-devel).

Went through http://wiki.sugarlabs.org/go/0.88/Platform_Components and
googled for how each project prefer patches to be submitted:

== Prefer a tracker ==

* http://www.gstreamer.net/wiki/SubmittingPatches
* http://dbus.freedesktop.org/doc/dbus-faq.html#id305110
* http://www.python.org/dev/patches/
* http://live.gnome.org/Git/Developers#Contributing_patches
* http://telepathy.freedesktop.org/wiki/Review%20Procedure
* http://wiki.immuexa.com/display/sq/Starting+with+Etoys+Development#StartingwithEtoysDevelopment-stepstomakeachange
* http://new.scipy.org/dev-zone.html#source-code

== Prefer a mailing list ==

* http://www.abisource.com/developers/
* http://www.pygame.org/wiki/patchesandbugs

== Unknown ==

* eSpeak
* csound
* libffi

>> - this whole bugtracker vs. mailing list issue may be a red herring
>> that we have come with to not have to deal with the real, harder
>> issues.
>
> I think it's one of many cases in which Sugar development is way too
> bureaucratic and procedural. Alienating the contributors who code mostly
> for fun is a big loss for a FLOSS project.

Look at the links above and read what are the processes to get changes
in. Again, I'm not saying that just because most of our dependencies
have processes for code contributions we need to have one, but at
least it shouldn't be assumed that it's because of some arbitrary
whim.

> In order to get any non-trivial patch in, one has to go through several
> stages of approval, each one managed by different people with
> contrasting opinions: design process,

Didn't knew we had a design process, do you have a link? 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.

> feature process,

This applies only to big enough features and is not mandatory to get
your code in. It just provides a consistent and predictive process to
whoever wants it, apart from helping out with release planning,
release notes, QA, etc.

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

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

> Often, the
> contributor gives up in exasperation before reaching approval. Even when
> a patch gets approved, time has been spent 10% coding and 90%
> interacting with web forms. Not fun.

Unhelpful hyperbole.

> Let's face it: Sugar development is damn boring! I hate to say something
> so negative, but Sugar is probably the *most boring* FLOSS project I've
> ever participated to.

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.

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.

> One would think that this is a necessary price we have to pay in the
> name of code quality, but how long does it take for a bug to be fixed in
> Sugar? Months. Sometimes years.

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 quality of our codebase is indeed
> very, very low and not improving very fast.

Now go through the code repositories of those projects.

> I'd rather take inspiration from the Linux kernel, which managed to
> attract the best hackers by making patch submission fast, easy and
> rewarding right from day 1. The book "Just For Fun" makes a good reading
> on how to bring a project to success with a $0 initial investment. One
> needs to engineer the process around social and psychological issues,
> the technical aspects come second.

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.

Regards,

Tomeu

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