On Oct 1, 11:25 pm, Christian Boos <cb...@neuf.fr> wrote: > See, *my* concern is that instead of discussing in a constructive way > about the practical problems the Trac code base has, and its possible > solutions, you come now with very high-level software engineering > advices, which feels a bit out of place. Thanks, but I do also read > occasionally, and in general, yes I prefer code that's easy to > understand and maintain. Especially given the fact that *I* maintain > that damn code base (not alone of course, but a good deal of it), and I > feel the pressing need for this simplification. > > So I really think the kind of philosophical discussion you started leads > nowhere. We need experiments, testing, people pointing shortcomings, > suggesting better APIs, improved datamodels, smarter ways of caching, > this sort of things. And at *that* level, feel free to exercise your > software engineering knowledge, there it will be useful and you know I'm > always open to suggestions, advices and *better* ideas than mine. > > As R my said, maybe it's now time for some code...
No doubt we can agree to disagree. But you seem to have misunderstood my reasons for not wanting all code to build on the same object model with all kinds of features poking out. It is not (surprise, surprise) to make it easier for you to maintain. Nor is it because some architecture is better or worse than others. As I said in the beginning of my first post, it is not about good or bad architecture. It is just about the differences and the changes and what it means for THIS project (in my opinion of course). My reason is to make it easier for me and everyone else to contribute and help out. It is to make it easier to move new features into Trac in a contained manner. It is to make it easy for new developers to come in and take responsibility for individual modules within Trac without needing to know all there is to know about all parts. The larger picture is saved for a few people like you and Remy that can with confidence make changes in all parts of Trac. My fear is that we change the Trac code base into a large, shared, generic code where you need to fully understand ALL consequences for ALL modules in oder to confidently change ANYTHING. If someone at some stage needs a tweaked handling for wiki module, such changes cannot be made directly without making a case before the "committe of shared code". An all-shared future brings with it a whole new class of problems. If your perspective is only how it makes it easier for YOU to maintain the code, I fear that what you then build will stay largely a one-man show. As I said before, heaps of credit to both you and Remy for all the effort you put in. This project is not a straight democracy, and the merit of your efforts now puts you in the driver seat for the future of the code base. What I'm trying to do (probably not all that well) is to influence how you think about the code, and what considerations you weigh when making your decisions. :::simon -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-...@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
