Providing feedback for submitted patches [was: new version]

Leandro Lucarella llucax at gmail.com
Wed Dec 2 17:11:34 PST 2009


Walter Bright, el  2 de diciembre a las 14:46 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el  2 de diciembre a las 13:29 me escribiste:
> >>>>I'd like to compare the user base and calculate the bugs/users ratio.
> >>>>I guess GCC's would be orders of magnitude smaller.
> >>>And BTW, GCC implements 7 languages (at least 7 languages are present as
> >>>bugzilla components: ada, c, c++, fortran, java, objc and objc++), so
> >>>doing a rough estimative, 5442/7 ~= 800, less than DMD, which implements
> >>>only D.
> >>>
> >>>Seriously Walter, you *can't* possibly compare DMD with GCC, it's almost
> >>>funny when you do it =P
> >>>
> >>My post was in response to the bug *count* being a showstopper. My
> >>point is it's absurd, because you can always slice the data to mean
> >>whatever you want it to mean. For example, many of the "bugs" in the
> >>dmd list are enhancement requests, bugs in the library (not the
> >>compiler), bugs in the documentation (not the compiler), etc.
> >
> >Sure, but your comparison with GCC just makes things more absurd, not
> >less. I completely agree with you that bug count (alone) is not a good
> >measure of compiler quality, I just don't agree with the GCC comparison
> >to prove it.
> 
> I *meant* to show it was absurd by showing the GCC bug list.

OK, my bad then. Sorry for the noise.

> >I hope you can change the license some time, and you start
> >encouraging other people involvement more actively, so the number of
> >contributors to DMD keep growing.
> 
> I encourage other people to submit patches. Don has been especially
> productive in this. But I still want to be the gateway to getting
> them integrated into the trunk, because otherwise I will lose track
> of how it works,

Sure, that's a good idea. Git (and DVCS in general) are very helpful in
managing projects like this, with a person in charge as a gateway.

> and because sometimes patches are not quite the right place to fix the
> problem, although they are usually close and still very helpful.

Maybe you could comment on patches, and tell people how to fix them to be
accepted, that help a lot when you're willing to contribute. It's really
frustrating when you make a patch and it's not accepted (or delayed) and
you don't know why. This way people can learn about the code too, and
where the fix should be really in, and how do you like patches to be
formatted, etc.

A mailing list (or NG) to submit patches and doing peer review would be
really nice, and I think it will be a big boost to
D open-source-friendliness, which will attract more people to contribute.
Right now it looks like making a patch is not much better than simply
suggesting a feature (or submitting a bug), even when in reality it could
be true that features or bugs with patches are much closer to make it,
because the lack of feedback. You never know if your patch is not applied
because it sucked, because is missing some little detail or because you
never saw it.

I hope you think about this, really, I think D is needing even more tools
to attract contributions :)

Thanks!

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
41% of all people take people with curly hair less seriously



More information about the Digitalmars-d mailing list