[torquedev] Approach towards small vs. big patches

David Beer dbeer at adaptivecomputing.com
Fri Nov 19 09:46:17 MST 2010

----- Original Message -----
> 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
> _______________________________________________
> torquedev mailing list
> torquedev at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torquedev

It might be helpful to set up a protocol for writing patches with the intent that they are included into the TORQUE source. We love it when the community contributes - that's really the way that we can make TORQUE a top notch resource manager - and we want to make sure that you know that we appreciate your contributions. Glen is right, we do need more people testing patches. Small patches can often be tested very quickly, and so we at Adaptive are often able to squeeze in time to test them enough that we're confident checking them in. Larger patches pose a much bigger challenge for us, because it is *very* difficult to find the time to adequately test them. Some more help testing would definitely speed up the process.

Additionally, we should probably discuss what kinds of patches are the most helpful to submit. We know that several sites have customizations that they make to TORQUE - this is part of the beauty of open source software - but not all of these customizations are things we can check in to the main body of TORQUE. Perhaps we can outline a criteria for patches to TORQUE. I can submit a few criteria for consideration:

1. Bugs. Obviously, we want to fix any bug we can find in TORQUE.
2. Things of general interest - the more generally a feature would be used, the more we would want to check it in to TORQUE
3. I'm also thinking that the bigger a change is, the more it should be discussed in the community. Its probably best to start discussing it in the community before developing it where possible. This can prevent efforts from being wasted, and I hate the idea of someone working on a patch only to find out it can't be applied for one hang up or another. 
4. I think #3 is especially applicable to behavioral changes and fundamental changes in TORQUE.

Please let me know your thoughts, add to this, take from it, etc. I think this is an important discussion to have.


More information about the torquedev mailing list