[torquedev] Approach towards small vs. big patches
knielson at adaptivecomputing.com
Fri Nov 19 12:31:15 MST 2010
On 11/18/2010 08:49 PM, Glen Beane wrote:
> 2010/11/18 "Mgr. Šimon Tóth"<SimonT at mail.muni.cz>:
>> I hate to criticise but I noticed a pattern when including patches from
>> If the patch is small, it is almost always included super fast (even if
>> it breaks everything or doesn't make sense at all).
>> On the other hand, longer patches just sit in Bugzilla with zero
>> activity (I have my own experience, but this is a general trend).
> I think the problem is there are too few developers evaluating
> patches, and not all developers are familiar with the entire code
> base. If we could get involvement from the community - several people
> saying this patch looks good, I've tested it, etc, then it might help
> speed things along
> I think individual developers might be reluctant to accept a large
> patch if they aren't super familiar with that part of the codebase
Glen and David have both made some good points.
From your post I am thinking of bug 67 and the patch you have submitted
there. I have downloaded it and tried to evaluate it but I have not been
able to give it the time needed to give a well reasoned opinion. The
patch introduces some new behavior that is working well for you but I am
not sure it is in general something that the community is looking for. I
am not saying it is what we want or not. But given time constraints and
the nature of the patch it has not been possible to look at this
thoroughly. I have asked a couple of other people in the community to
evaluate your patch but they have the same issue with time and priorities.
Most of the smaller patches that have been submitted have been for bug
fixes. The problems have been easy to evaluate so it has been easy to
accept the patches.
I regret I was not able to meet with your colleagues at SuperComputing.
I would have liked to have had a face to face discussion to better
understand what you are doing.
More information about the torquedev