Jani Tiainen wrote: > Ilias Lazaridis wrote: > > 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. > > AFAIK it works so that you attach patch to ticket (or create new ticket > if no suitable is found), it's revieved and applied as it fits.
yes, that's the existent process... > > This is mainly to avoid rejection of patches, e.g. due to personal > > reasons, non-understanding reasons (e.g. due to missing time) etc.! ...which leads to unnecessary rejection of patches. > > 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. > > Who makes decision that patch doesn't break existing behaviour? sometimes simple logic, see below. > > 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. > > Again.. Who has decided it doesn't break existent code? Is it > guaranteed that it doesn't contain bugs? there are refactoring steps which can be even automated, thus a machine could decide that existent behaviour is not broken. > What if patch contains some malicious stuff? It don't break anything > but it's according to rules stated here to get it applied without any > discussion. Means a requirement must be added (although "should not contain malicious stuff" should be an obivous requirement). > What if patch is not in line with coding style, naming conventions and > such? You suggested that it still would be applied without any > discussion. you can add "coding style" and "naming conventions" to the "patch requirements list". > Only a trivial patch would be handled this way. Since existence of such > patch is just a hoax, it's pretty much unfeasible. And those trivial patches are the 'refactoring patches'. Many simple, trivial, tiny patches. Reviewers can verify them against standard-requirements (to give a 'pre-ok'). A few committers, which apply the pre-ok patches after the final review. This can bring a code-base step by step into a healthier status. And this allows contributors to reuse the original code, as they have the guarantee that "mechanical refactoring patches" get applied anyway (if they follow naming guidelines etc.). . -- http://dev.lazaridis.com/base --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
