[Sugar-devel] Bug tracking Vs Patch review

[Tomeu Vizoso]

On Mon, Aug 30, 2010 at 14:44, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> 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

Forgot about the most complex review process I have seen:
https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch

WebKit has a more standard one: http://webkit.org/coding/contributing.html

Regards,

Tomeu

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