[torquedev] Approach towards small vs. big patches

"Mgr. Šimon Tóth" SimonT at mail.muni.cz
Fri Nov 19 12:49:30 MST 2010


On 19.11.2010 20:31, Ken Nielson wrote:
> 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
>>> Bugzilla.
>>>
>>> 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
>> _______________________________________________
> Simon,
> 
> 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.

My patch is extreme in this context. I know it's huge. On the other hand
I have a big blob of features waiting to be applied against both the
server and the FIFO scheduler based upon this feature.

Plus I was speaking more generally. Look at the number of open bugs in
bugzilla, it seems to be growing steadily.

It would be great if the patch accepting process would be well defined
and more open (something similar to the hierarchic model used by Linux
kernel would be awesome). It doesn't have to be some huge formal
document, just a simple 3-5 step process.

For example, there were already several discussions about not accepting
features into 2.x-fixes branches, but they still are accepted (just not
from external sources).

Sure it will take some time to establish some rules, but until these
rules are established and enforced the same problems will keep appearing
again and again.

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

Well, what I feel is a little overzealous approach towards smaller
patches, I managed to stop one of two bug fixes I didn't like (coming
through bugzilla), the one I managed to stop (Bug 98) actually finished
with a working patch. But I think, that small bug fixes need way more
evaluation than is currently given.

Usually the first reaction is "Thx for patch, will be committed ASAP"

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

Oh :-/ That's unfortunate. Hopefully there will some other event soon.

-- 
Mgr. Šimon Tóth

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3366 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.supercluster.org/pipermail/torquedev/attachments/20101119/99936d3e/attachment.bin 


More information about the torquedev mailing list