Ilias Lazaridis wrote: > 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...
And works pretty well from personal experience. > > > 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. Depends who decides what is "unnecessary" and which is not. > > > 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. Meaning by blindly trusting? Oh, set of rules involving human intervention... (note the sarcasm here) > > > 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. Machine could, but it can't. It can only run predefined set of tests and see if output is same. It can't never be as intuitive as enduser. > > 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). But then it would need attention, reviewing? > > 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". More need for manpower to review patch... > > 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. There is no such thing as trivial patch. > 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. Um... Isn't that contradictory with original idea to get it commited without discussion, immediately..? Now you're saying that it must be reviewed (and thus maybe discussed, or even rejected). You can't have both immediate applying "trivial" patches and reviews to some ruleset, unless you get someone to watch patches 24/7... > This can bring a code-base step by step into a healthier status. Determined by who and by which factors? > 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.). In collaborative environment you can't really do refactoring (except method extracting) without breaking "original code". -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
