In order to engourage other projects to use the *original* trac source code base instead of writing customized code, a patch acceptance and application policy should be provided.
This is mainly to avoid rejection of patches, e.g. due to personal reasons, non-understanding reasons (e.g. due to missing time) etc.! A patch from a contributor A could be rejected, but the patch would be of benefit for the reusability of the trac-code-base, and thus for all other users. A example rule of such policy could be: * A patch which makes a function general, thus it can be used from outside of trac-application * should be applied *immediately*, if the existent behaviour is not broken. - An example: This patch would pass without *any* discussion, as it enables the "load_components" function (implemented as one function with one env parameter) to be used in conjunction with searchdirs passed as an optional parameter: http://trac.edgewall.org/attachment/ticket/4317/LoaderOptionalSearchdirs.diff this way, the following external project could use the original "load_components" http://dev.lazaridis.com/base/browser/infra/tracx/tracx/loader.py?rev=156#L58 This would happen without breakage of the existent code. - sidenote: Of course, the mega-function "load_components" would need some more refactoring in order to become more flexible and maintainable: http://trac.edgewall.org/browser/trunk/trac/loader.py?rev=rev%3D3557#L34 . -- http://dev.lazaridis.com/base/wiki --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
