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.
Well, seems to me that encouraging other projects to use trac code isn't the first (nor second, likely) priority of Trac and the dev team. While I don't think they should make decisions lightly that will purposely hinder other projects from using Trac as a base, I don't really see this as being a good reason for implementing a "patch acceptance and application policy" >>> 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. And who determines what is an unnecessary rejection? This all boils down to differences in opinions and priorities. And when you get to that level, the devs have ultimate authority. So if it's necessary to them, then it's basically necessary to all. >>> 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. As I stated above, while making it easy for other projects to use as a base is nice, it's not a priority. Also, it's hard to decide what consequences a simple patch might have in the future. Sure, you provide a nice interface now, and lots of external projects start using it, but what happens when you realize that to further Trac, you need to break that interface which really only serves external projects? Sure, you can go ahead and simply break it in the name of progress, but then you have tons of external projects complaining. >>> 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. A policy like this introduces too many patches for too little gain. See previous paragraph re: unintended future consequences. >>> 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: While I'm actually for the stated patch itself, having any patch be applied "without *any* discussion" due only to the fact that "existent behaviour is not broken" is a VERY bad idea, IMNSHO. You're opening yourself up to abuse and lots more complaints. The fact remains that the devs have absolute authority over which patches they accept and which they don't. The should not be holden to some stupid policy telling them which patches they MUST accept. If the time comes that all the Trac devs have suffered severe brain damage and are hindering the project because of their poor decisions and refusal to accept patches, then the project will be forked[1]. That's the OSS way ;) > This can bring a code-base step by step into a healthier status. Who determines the health of the code base? For what I've read of the trac code, which is a fair amount, it is generally of very high quality. > 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.). Guarantees of that sort are bad. OSS is generally seen as a meritocracy. Which means that the best code is accepted. Having some policy (which is hard enough to define) that is used as a rule by which code is accepted, is a BAD idea. I have said it before, and I'll say it again. The Trac devs have the ultimate authority on what they accept and what they don't. Any attempt to change this is bad. I trust their decisions, direction, and competence. And to their credit, look where it has brought trac. -John [1] However, from getting to know the Trac devs, I think we are VERY, VERY far from this. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
