On Fri, Oct 1, 2010 at 11:25 PM, Christian Boos <cb...@neuf.fr> wrote:
> On 10/1/2010 9:47 PM, osimons wrote: > >> On Oct 1, 5:16 pm, Christian Boos<cb...@neuf.fr> wrote: >> >>> [uber-snip] >> >> >> >> I've stayed with the project for a long time, and I'm planning to stay >> on. I'll respect the direction the majority want to take, and as you >> also said it is really only fair that when you write the code you have >> much more important say in what should be done and how. I have no >> problem with that. I do however want to use my voice to express my >> concerns about this direction. >> >> > 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... > > -- Christian yayks. I didn't know this was such a hot potato (or pandora box, or can of worms, or a better phrase in Hebrew that I cannot share or translate). At least it triggered some discussion, and maybe some code to follow! :-) I do agree a lot with a comment by Remy on the IRC - "Try something, if it looks good, improve and extend. If it doesn't, drop it and try something else. All of this on a small part of the code." And I think that the direction that Christian is taking (experiment with the Ticket module) is exactly that (try something on a small part of the code), as long as we remember to stop and evaluate between the ticket module and spreading it to other modules. >From the discussion (and IRC), I think we can actually leverage the "opposing camp" with the "strong opinion" by asking Simon (and those who agree strongly with his view) to formulate criteria for evaluating the benefit of the ticket module experiment. Anyway, I will try to pick up Christian's hints later on, maybe with some of my ideas, although I think I have a simplistic and naive comprehension of the existing model(s), as a result of not having years of experience with the code base (or even plugin development). > > > -- > 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<trac-dev%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/trac-dev?hl=en. > > -- 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.
